Pkg xen devel - Jan 2017 - Feedback on merge of Xen-4.8.0

Hi Ian,

first thanks for picking up so many things in your upload. Unfortunately it took
me a while to merge this back into Ubuntu. So it is a bit late for the feedback
but I hope it still helps a bit.

Sadly I think that by picking up the grub default file, you picked up some
trouble. It is not the contents but the packaging. Logically it belongs to the
hypervisor, but that is versioned in Debian to be able to have 2 versions
installed in parallel. But that breaks now with the same config file being in
both. I get away with that in Ubuntu because we do support only one version
installed and I add transitional hypervisor packages. I believe the right move
would be to have a xen-hypervisor-common but am not sure how one would make a
safe transition there. Maybe together we can work something out.

Other than that, there are two (and maybe a haf) things that might be beneficial
for Debian:

1. Users have noticed with Ubuntu's Xen-4.7 (still true with 4.8) that some
   tools (mainly gdbsx, but also some flask-* commands) are missing from the
   xen-utils-4.x package. This is because those end up outside the libexec
   path. The attached diff fixes this (a bit hackish) by simply copying all
   those into usr/lib/xen-$(VERSION)/bin/

2. Splitting up xen.init. Initially driven by systemd in Ubuntu trying to
   unmount everything on shutdown/reboot. And with xenstore still running
   this would always lead to error messages. So I split the init scripts
   into a xenstore.init and xen.init part. The additional benefit is that
   this allows to separate the init scripts clearly into one that is re-
   started on upgrade (xen.init) and one which is not (xenstore.init). And
   both parts will stop on shutdown/reboot allowing xenfs to be unmounted.
2.5 Part of those script split is some adjustments to the LSB headers. Most
   importantly the reference to libvirtd. The became important because in
   Ubuntu (maybe now also true in Debian) the helpers that create the sysv
   init S/K-script links ignore the numbers passed in by dh_installinit and
   now re-number everything based purely on the dependencies defined. So we
   had the problem that libvirtd would potentially be starting in parallel
   with Xen, leading to cases where libvirt would not detect the hypervisor.

-Stefan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: maybe4debian.diff
Type: text/x-patch
Size: 8356 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20170125/11508937/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20170125/11508937/attachment.sig>

Stefan Bader writes ("Feedback on merge of
Xen-4.8.0"):
> first thanks for picking up so many things in your
> upload. Unfortunately it took me a while to merge this back into
> Ubuntu. So it is a bit late for the feedback but I hope it still
> helps a bit.
Thanks.  I will look at this today.

Debian's migration freeze is 10 days from today and there are now
mandatory 10 day migrations.  So it is possible that whatever fix I
come up with will need a freeze exception.
> Sadly I think that by picking up the grub default file, you picked
> up some trouble. It is not the contents but the packaging. Logically
> it belongs to the hypervisor, but that is versioned in Debian to be
> able to have 2 versions installed in parallel. But that breaks now
> with the same config file being in both. I get away with that in
> Ubuntu because we do support only one version installed and I add
> transitional hypervisor packages. I believe the right move would be
> to have a xen-hypervisor-common but am not sure how one would make a
> safe transition there. Maybe together we can work something out.
Do you want to file a bug ?  (Severity: important)

If you don't, I will.
> Other than that, there are two (and maybe a haf) things that might
> be beneficial for Debian:
I don't think any of this is doable at this stage of the Debian
release.

Ian.

Ian Jackson writes ("Re: Feedback on merge of
Xen-4.8.0"):
> Stefan Bader writes ("Feedback on merge of Xen-4.8.0"):
> > first thanks for picking up so many things in your
> > upload. Unfortunately it took me a while to merge this back into
> > Ubuntu. So it is a bit late for the feedback but I hope it still
> > helps a bit.
> 
> Thanks.  I will look at this today.
> 
> Debian's migration freeze is 10 days from today and there are now
> mandatory 10 day migrations.  So it is possible that whatever fix I
> come up with will need a freeze exception.
Looking at this some more, I think you are probably right that the
best answer is a xen-hypervisor-common package.

Another possibility would be to put this file in xen-utils-common,
which produces one fewer silly packages, but means that it is possible
to install the hypervisor in a way that means it won't be booted by
default and if you did boot it, it and the kernel would have
suboptimal command line arguments.

But: I don't think any of this needs to be done in Debian's Xen 4.8
packages.  I reason as follows: Debian's Xen 4.8 are coinstallable
with earlier packages because those earlier packages don't have this
file.

And in Xen 4.9 or 4.10, in Debian buster, we can introduce the new
package and put in a Replaces with transfers the conffile to the new
ownership.

I am going to test now to see whether that works well.  If it does I
will file a bug with the appropriate patch.

If it doesn't then it would be good to sort this out in stretch and I
will negotiate with the Debian Release Team about that.

FYI, apropos of your other comments: I came to the Xen packages quite
late in the stretch cycle, mostly because I felt we definitely needed
Xen 4.8.  So there are many things which I didn't want to change.

Early in buster I intend to completely overhaul the packaging.  I am
also one of the Xen upstream maintainers so I should be able to
dramatically reduce the Debian delta.

Ian.