Re: Notes from Xen BoF at Debconf15

[Ian Campbell <ian.campbell@citrix.com>]

On Tue, 2015-09-08 at 09:49 -0500, Doug Goldstein wrote:
> > Midlevel library stability
> > ==========================
> > 
> > libxenlight is only API not ABI stable. This is a pain in particular
> > for libvirt which needs binNMU for new Xen package.
> > 
> > We would like to eventually offer ABI stability or this library, but
> > we are not there yet.
> 
> What about doing symbol versioning like libvirt does to start offering
> ABI stability? You could then at some point in the future do a ABI break
> to remove out the bits that were deprecated when you do the "1.0"
> release.

I think symbol versioning will indeed be one of the tools we will need to
deploy when we are ready to declare ABI stability for the library.

However symbol versioning only really helps if the ABI is already "almost
stable", if you try to use it to make a library which is undergoing a great
deal of ABI churn appear stable then you have to hand craft an enormous
amount of compatibility code to massage data structures between the
different versions.

I think we are getting towards being "almost stable" enough, maybe in a
release or two.

> > Stubdomains
> > ===========
> > 
> > Hard to do in a packaging environment (is really its own partial
> > architecture). Rump kernels are no different in this regard.
> > 
> > No clever ideas were put forward.
> 
> Honestly what about moving these more out of tree? Now with mini-os
> being out of tree and the stubdoms needing mini-os its an absolute mess
> to build from a distro standpoint since mini-os is git fetched. To make
> it work upstream using raisin would be a great improvement here.

IMHO where the code lives is not the hardest thing with packaging
stubdomains from a distro PoV, see the "On distro packaging of stub
domains" subthread.

That's not to say where the code lives couldn't be improved, and raisin is
certainly a path to improving that, partly by exposing devs to the distros
pain.

Ian.