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

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.

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!

-- 
-- Stevie-O
Real programmers use COPY CON PROGRAM.EXE
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20181013/06e57222/attachment.html>

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

On Sat, Oct 13, 2018 at 6:23 PM Hans van Kranenburg <hans at knorrie.org>
wrote:
>
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?
>
(1) apt-get -t unstable install libxen-dev  (installed v4.11)
(2) apt-get source qemu-system-x86
(3) dpkg-buildpackage -uc -us
(4) dpkg-deb -I qemu-system-x86_*.deb | grep Depends

I should point out that this is correct: libxenmisc4.11 includes
libxenctrl, which qemu uses for PCI passthrough management (and probably
other things.)
This can be confirmed by running
    ldd debian/qemu-system-x86/usr/bin/qemu-system-i386 | grep xen
after the build: libxenctrl is in the list.
(note: that command is from memory; if it doesn't work, use find  -name
'*i386' to get the right path)


> If you want to follow progress around Xen in Debian Unstable, I can
> recommend to subscribe to the related mailing list:
>
Already there :) That's how I knew that Xen 4.11 had transitioned from
experimental to unstable  -- and the reason I took a close look at the
packaging in the first place.

Now I just need to figure out how to make Gmail *not* default to
top-posting...

-- 
-- Stevie-O
Real programmers use COPY CON PROGRAM.EXE
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20181013/0d5f6807/attachment.html>