[Pkg-xen-devel] My Xen package plans/thoughts/ideas for Jessie

[Ian Campbell]

On Thu, 2012-10-04 at 15:43 +0200, Bastian Blank wrote:
> On Thu, Oct 04, 2012 at 09:54:40AM +0100, Ian Campbell wrote:
> >       * UEFI support. Build and install the necessary hypervisor binary.
> >         Integrate with bootloaders as necessary.
> 
> Can't it use the same binary for UEFI and BIOS like Linux does since a
> long time?

TBH I need to investigate this a bit more but I know that there is a
special Xen EFI binary which gets built, but I don't know if it is
compulsory or some sort of optional thing. I think it implements its own
EFI shell (if that's the right term).

Might be something to do with needing multiple multiboot modules?

I mostly going on http://xenbits.xen.org/docs/unstable/misc/efi.html
here, which doesn't really explain the why it is this way part.

> 
> >       * Enable ARM port. Depends on upstream progress of course, but
> >         once this is in reasonable shape I'd obviously want to enable it
> >         for armhf and arm64.
> 
> No problem.
> 
> >       * Toolstack virtual package, split existing package into common,
> >         xm/xend and xl. xcp-xapi could also provide the virtual package
> >         allowing only the desired toolstack to be installed.
> 
> Please describe this a bit more.

Currently we have, roughly, xen-utils-common and xen-utils-X.Y (lets
ignore lib*, xenstore-utils etc for now). The xen-utils-X.Y package
contains both xl and xm/xend. In addition we also have in the archive
xcp-xapi which also provides a Xen toolstack.

I'm proposing to split this into:
xen-utils-common
        same as today
xen-utils-common-X.Y:
        stuff used by all toolstacks, this is most of the stuff which is
        currently in xen-utils-X.Y that isn't in one of the following
        packages.

xen-toolstack-xl-X.Y (name TBD, perhaps xen-utils-xl-X.Y?)):
        the xl binary and related stuff

xen-toolstack-xend-X.Y (name TBD):
        xm and xend related stuff, perhaps including python bindings for
        xc and similar stuff (although they are arguably better in -common-X.Y).

xen-toolstack-{xl,xend}-X.Y and xcp-xapi would Provide
xen-toolstack-X.Y.

Packages which currently recommend xen-utils-X.Y would instead recommend
"xen-toolstack-$DEFAULT-X.Y | xen-toolstack-X.Y" (where DEFAULT might
initially be xend and transition sooner or later to xl).

This allows people to only install the toolstack they are interested in
using, helps us transition from xend->xl and to deprecate xend when the
time comes. I suspect it could also be used to simplify the $TOOLSTACK
stuff via /etc/defaults/xen.

It's an open question whether the xen-toolstack-*-X.Y packages should
also conflict/replace xen-toolstack-X.Y. It seems like being able to
install e.g. xl and xcp-xapi simultaneously might be somewhat useful for
debugging and things like that.

There's probably scope for going even more fine grained splitting e.g.
put the language bindings in their own packages and splitting up the
various classes of utils a bit but I think that would be taking things
too far.

> >       * Rejig the tools install targets to allow use of dh_install
> >         --list-missing or --fail-missing. I'm not sure if this is
> >         worthwhile but there's a small number of bugs filed about
> >         missing this and that (e.g. man pages) which might have been
> >         avoided if we could use these. This might be a case of trying it
> >         and seeing.
> 
> Not sure what you think about. But please notice that the xen package
> build both arch-all and other packages, so you can't move it into one
> target.

Hrm, yes that might be a problem.

Looks like "dh_install --list-missing" can't really work with any
non-trivial package which has both arch and indep packages or which
wants to run things via multiple invocations (with -X) for any reason.
It seems like this is probably the majority of packages. I'll have a
play and see what (if any) options there are to help us avoid missing
installation of new bits, this probablem can't be unique to the Xen
packages.

I forgot another couple of items:
      * Enable ocaml xenstored (oxenstored). Not sure if we do this
        already done in the 4.2 packaging. I'd like to make it the
        default if possible. Not sure if this is worth dual packages
        allowing users to choose or if we should just pick one.
      * Package libxenlight so others can link against it, at least
        libvirt and xcp-xapi (at some point in the future) are going to
        want to do this.

Ian.
-- 
Ian Campbell

If swimming is so good for your figure, how come whales look the
way they do?