Pkg xen devel - Feb 2019 - Bug#921187: Getting rid of rdepends on libxenmisc4.X so we can do backports

Package: src:xen
Version: 4.11.1-1

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,

On 2/2/19 9:25 PM, Hans van Kranenburg wrote:
> 
> 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.
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

On Tue, 5 Feb 2019 20:41:17 +0100 Hans van Kranenburg <hans at
knorrie.org> wrote:
> ...led me here...
> 
>
https://salsa.debian.org/qemu-team/qemu/commit/a6a863e912bf03bb321dead3a98c755951665ced
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL:
<http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20201219/66174bd3/attachment.sig>

I see the mail thread 'RFC: qemu and Xen ABI-unstable libs' on the 
upstream xen-devel mailing list did not get referenced from this Debian 
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.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445