Currently, these are rdepends: -$ apt-cache rdepends libxenmisc4.11 libxenmisc4.11 Reverse Depends: libxen-dev xen-utils-4.11 collectd qemu-system-x86 libvirt-daemon collectd-core It's on the wishlist to start doing buster-backports for Xen. If the user has a cluster of servers and can make use of live migrate, then this allows the user to keep rolling-upgrading and following new Xen releases without domU mass-reboots and downtime. Live migration is only supported from N to N+1 versions, so e.g. from 4.10 to 4.11, but not e.g. from 4.4 to 4.10. The qemu one here is the most important/urgent one. Having this dependency means that users of backports cannot use HVM, or that there also need to be qemu backports. When redoing the packaging in Q3 2018, all libraries with upstream stable ABI were split off into packages with its own version number, like libxendevicemodel1, libxenevtchn1, etc. We think there's technically no reason that qemu has to depend on libxenmisc4.11, so maybe it's the shlibs machinery that is confused. Task here: find out why this is happening and see if the dependency can be removed. Apparently collectd and libvirt have a similar problem.
Actually, I think the first reason why this dependency was brought up during last friday was the fact that when qemu gets upgraded to the binaries built against 4.11, but the 4.8 hypervisor is still running, it's no longer possible to start a new domU which uses qemu. Also note that this is not a new problem, it has always been like this. However, in the "upgrade notes" that we should have somewhere we must strongly recommend to not do anything else than shutting down or saving the running domUs and rebooting the host machine ASAP after upgrading the Xen packages.
FYI this... https://lists.xenproject.org/archives/html/xen-devel/2019-01/msg01696.html ...led me here... https://salsa.debian.org/qemu-team/qemu/commit/a6a863e912bf03bb321dead3a98c755951665ced ...which resulted in... https://packages.debian.org/sid/qemu-system-x86 ...which still depends on libxenmisc4.11 (insert Monty Python's Dramatic Chord) I was hoping for just a second we would have been lucky here. :D K
That commit added the do-not-link-everything-with-xen.patch That patch got removed in a commit named 'update for v4.1'. https://salsa.debian.org/qemu-team/qemu/-/commit/9137f667a7ccbcf7441d878a9443fab142cfd907 But even today, 2020-12-19, there is still something in qemu which links to libxenmisc<version>. I don't know how, but I guess it should be possible to determine which part/function it is linking against and then see if that can be split off into a version independent package.
bug yet: https://lists.xenproject.org/archives/html/xen-devel/2020-09/threads.html#01299 It contains a lot of info about the actual work that needs to be done. Hans
From looking, it doesn't appear necessary to remove the dependency of QEMU on libxenmiscX.YY to make backports possible. According to DPKG, multiple versions of libxenmisc can be installed at the same time, so the issue is simply whether multiple versions of QEMU can be installed at the same time. Last time I tried, it was /almost/ possible to install the testing version of Xen on an otherwise stable system. The only dependency issue was the testing version of Xen needed an incompatible version of libc. Backports already look 99% possible.