<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">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:<div><br></div><div>1. libxen-dev is a single package with two versions: a 4.8 version and a 4.11 version<br></div><div>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</div><div>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</div><div><br></div><div>There doesn't seem to be a way by which qemu could be packaged to work with *either* 4.8 or 4.11:</div><div>If you have a qemu that was compiled against libxen-dev=4.8, your qemu will *only* use the libxen-4.8 files.</div><div>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.</div><div><br></div><div>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.</div><div>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!</div><div><br></div><div>-- <br></div><div><div><div><div><div dir="ltr" class="gmail_signature">-- Stevie-O<br>Real programmers use COPY CON PROGRAM.EXE<br><br></div></div></div></div></div></div></div></div></div></div>