[Pkg-xen-devel] Bug#1028251: New Patch (Was: Re: Bug#1028251: xen: FTBFS when building xen binary packages for sid on x86_64)

[Marek Marczykowski-Górecki]

On Sat, Jan 14, 2023 at 12:59:04AM +0100, Hans van Kranenburg wrote:
> The project plan (that could be drafted on an A4 paper) could look like,
> gather around all distro maintainers of Linux distro's that are shipping
> Xen, and then search for a 'Project owner', which we totally need to be
> someone that is actually employed at a company that actually cares about
> getting the results of this.

While Qubes release upgrade would benefit from this feature a bit (but
see remark at the end), I'm afraid it isn't high enough on our priority
list to dedicate enough time for this... In a long term, I'd rather
invest in making hypervisor ABI itself stable, so libxenX.Y would work
with Xen X.Y-n too. That's rather far away, but AFAIK it is on Xen
upstream roadmap.

> Then we go look at the Debian stuff and fix upstream to do the same
> thing, also fixing all the init/systemd stuff that got lost along the
> way, and then we can push it down to all other distro's as well again.

IIUC, since Debian ships wrappers for various Xen tools that choose the
right version, just getting native systemd units shouldn't be that hard.
But yes, syncing those init scripts back together is substantially more
work.

> And after all of that is done, there will be a time where we actually
> (at Debian) can have a different response to everything init script
> related than "sorry, probably won't happen".

FWIW, we have a bodge for 922033 as a package that patches some of those
init scripts:
https://github.com/qubesOS/qubes-vmm-xen-guest
(xendriverdomain.service is shipped via another package, for historical
reasons).

> If you look at the init script stuff in Xen upstream already, it quickly
> shows that it's just a total dumpster fire. Someone cobbled up something
> in the year 2005, and after that, only changes have been made by people
> who actually tried to touch it for a few seconds with a 10-foot pole.

systemd units are likely in significantly better shape. They are
actually used in production at least by Fedora, Qubes and OpenSUSE,
contrary to legacy sysvinit scripts.

> So, nobody is really caring about this. There is not an actual person
> upstream who is involved into this. As long as that's the case, it's not
> a healthy thing for ourselves to start to try fixing all of that from a
> downstream POV.
> 
> We're currently doing 'good' with the Debian Xen Team, I think. We can
> keep up with security updates, and we're in some sort of OK position to
> get the essential stuff into place for Bookworm, but to say it in good
> Dutch "Nee, het houdt niet over...".
> 
> Knorrie
> 
> P.S. and if you think "I have no idea what you're rambling about
> Knorrie, I have never experienced that problem", well, then thank you
> for using Debian ;]
> 
> *) Yeah, this works for PV and PVH, but until the #$^$%& qemu stops
> using internal unstable function calls any more so that it doesn't have
> to hard depend on libxenmisc4.1X any more, you're still screwed for HVM.
> BUT! if you just shut down the domUs nicely and reboot and you have to
> go back, then dpkg -i or whatever the previous qemu and you can still
> start all domUs again instead of going into full panic mode during the
> night.

Unfortunately the same caveat applies to libvirt, and while qemu uses
only very few functions from the unstable API, with libvirt it's the
whole libxl, so it's very far from dropping that pain point...
So, if you manage Xen domains via libvirt, not xl directly, you're
screwed in PV and PVH case too.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20230114/4d0bf427/attachment.sig>