[Pkg-xen-devel] libxen-dev, libxen-4.8: Potential upgrade path issues with regard to qemu

[Hans van Kranenburg]

Hi Stephen,

On 10/13/2018 11:28 PM, Stephen Oberholtzer wrote:
> While attempting to troubleshoot a problem with PCI passthrough, I
> noticed a number of facts that, when considered together, may indicate a
> serious upgrade path issue with regard to Xen and QEMU:
> 
> 1. libxen-dev is a single package with two versions: a 4.8 version and a
> 4.11 version
> 2. libxen-dev version 4.8 produces libraries with 4.8 in the soname.  A
> qemu compiled against this version has Depends: libxen-4.8
> 3. libxen-dev version 4.11 produces libraries with no version number in
> the soname (except those in libxenmisc).  A qemu compiled against this
> version has Depends: libxendevicemodel1,  libxenevtchn1, 
> libxenforeignmemory1, libxengnttab1, libxenmisc4.11
> 
> There doesn't seem to be a way by which qemu could be packaged to work
> with *either* 4.8 or 4.11:
> If you have a qemu that was compiled against libxen-dev=4.8, your qemu
> will *only* use the libxen-4.8 files.
> If you have a qemu that was compiled against libxen-dev=4.11, your qemu
> will use the latest version of 4.11-style-packaged libraries, except for
> libxenctrl and libxenguest, which will always use 4.11.

You're right to notice that there's something going on here.

Until the recent uploads to unstable, the Xen packaging did just put all
libraries together in the libxen-x.y package, which resulted in a qemu
always depending on libxen-x.y with same x and y.

Very recently (this weeks changes in the archive), the packaging code
that is being used has been rewritten. Upstream, there's quite a number
of xen libraries that have a stable ABI. The rewritten packaging takes
this into account, which results in an additional number of explicit
binary packages for e.g. libxengnttab1. The remainder of the libraries
that do not have the "stable" blessing from upstream are packaged into
libxenmiscx.y now.

One of the resulting things that is on our TODO list now is to find out
how qemu is dealing with this. Debian Unstable is the right place to get
this done.

Instead of depending on a xen version specific thing, we were hoping the
qemu build would start depending on one or more of the stable library
packages, but *not* the version specific one.

Since we didn't get to this yet in the last few days, can you please
provide more information about what you did to find out why qemu in
current unstable will depend on the new libxenmisc4.11?

Having qemu depend on non-xen-version specific packages will make it
possible for us to start providing buster-backports packages that can
also do HVM things.

> I understand that dealing with this is at least partially the
> responsibility of the Debian QEMU Team, which is why I've CC'd them.
> However, this seems to suggest that qemu packaging would need to be
> updated in lockstep with Xen, even if someone is using qemu in kvm or
> standalone mode!

So, this is simply one of the next TODO items, and thanks for already
jumping into them. :)

If you want to follow progress around Xen in Debian Unstable, I can
recommend to subscribe to the related mailing list:

https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-xen-devel

Thanks,
Hans