Pkg xen devel - Jan 2021 - [PATCH 06/16] debian/control: Update utils Recommends

On Fri, Jan 15, 2021 at 06:24:44PM +0100, Hans van Kranenburg
wrote:
> On 1/2/21 9:30 PM, Elliott Mitchell wrote:
> > @@ -102,7 +102,7 @@ Section: admin
> >  Architecture: amd64 arm64 armhf i386
> >  Provides: xen-utils
> >  Depends: ${shlibs:Depends}, ${misc:Depends}, python3,
xen-utils-common (>= ${source:Version})
> > -Recommends: bridge-utils, libc6-xen [i386], xen-hypervisor-4.14,
qemu-system-x86, grub-xen-host [i386 amd64]
> > +Recommends: ovn-host|bridge-utils, libc6-xen [i386],
xen-hypervisor-4.14, qemu-system-x86, xen-domu-bootloader|grub-xen-host
> 
> This immediately makes ovn-host the default. We should not do that
> unless there have been a huge amount of improvement in the user
> documentation (e.g. cleaning up the mess that wiki.debian is).
I was unaware order had that level of significance.  Instead use
"bridge-utils|ovn-host"?

> xen-domu-bootloader does not even exist as package. It does not make any
> sense to add it.
The idea is "xen-domu-bootloader" would be a virtual package
potentially
provided by several packages.  Ideally "grub-xen-host" would start
providing it.  If/When PyGRUB is broken off of xen-utils-X.YY, then the
PyGRUB package could provide "xen-domu-bootloader".

More notably, "xen-domu-bootloader" could be provided by Xen builds of
EDK2/Tianocore or U-Boot.  I've been advised EDK2/Tianocore can be used
to successfully boot Windows on Xen/ARM.  EDK2/Tianocore may be more
attractive as a bootloader for FreeBSD on amd64 instead of PvGRUB.  I'm
presently trying to see whether U-Boot can get FreeBSD/ARM to boot (this
could be a driver issue for FreeBSD, but there are also hints FreeBSD
prefers device-trees on ARM).

There is also an ordering issue with the two options.  I suspect rather
more OSes can be loaded by EDK2/Tianocore than by PvGRUB, so I'm inclined
to pushing a generic virtual package over PvGRUB.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

On 1/15/21 7:38 PM, Elliott Mitchell wrote:
> On Fri, Jan 15, 2021 at 06:24:44PM +0100, Hans van Kranenburg wrote:
>> On 1/2/21 9:30 PM, Elliott Mitchell wrote:
>>> @@ -102,7 +102,7 @@ Section: admin
>>>  Architecture: amd64 arm64 armhf i386
>>>  Provides: xen-utils
>>>  Depends: ${shlibs:Depends}, ${misc:Depends}, python3,
xen-utils-common (>= ${source:Version})
>>> -Recommends: bridge-utils, libc6-xen [i386], xen-hypervisor-4.14,
qemu-system-x86, grub-xen-host [i386 amd64]
>>> +Recommends: ovn-host|bridge-utils, libc6-xen [i386],
xen-hypervisor-4.14, qemu-system-x86, xen-domu-bootloader|grub-xen-host
>>
>> This immediately makes ovn-host the default. We should not do that
>> unless there have been a huge amount of improvement in the user
>> documentation (e.g. cleaning up the mess that wiki.debian is).
> 
> I was unaware order had that level of significance.  Instead use
> "bridge-utils|ovn-host"?
Yes. At least that will not also drag in the bridge stuff as well. And,
it is a nice hint for sysadmins configuring their dom0s with something
like puppet about what package they should install.

I have been using xen with openvswitch instead of bridges forever, but
never ran into this because I never install Recommends.
>> xen-domu-bootloader does not even exist as package. It does not make
any
>> sense to add it.
> 
> The idea is "xen-domu-bootloader" would be a virtual package
potentially
> provided by several packages.  Ideally "grub-xen-host" would
start
> providing it.  If/When PyGRUB is broken off of xen-utils-X.YY, then the
> PyGRUB package could provide "xen-domu-bootloader".
> 
> More notably, "xen-domu-bootloader" could be provided by Xen
builds of
> EDK2/Tianocore or U-Boot.  I've been advised EDK2/Tianocore can be used
> to successfully boot Windows on Xen/ARM.  EDK2/Tianocore may be more
> attractive as a bootloader for FreeBSD on amd64 instead of PvGRUB.  I'm
> presently trying to see whether U-Boot can get FreeBSD/ARM to boot (this
> could be a driver issue for FreeBSD, but there are also hints FreeBSD
> prefers device-trees on ARM).
> 
> There is also an ordering issue with the two options.  I suspect rather
> more OSes can be loaded by EDK2/Tianocore than by PvGRUB, so I'm
inclined
> to pushing a generic virtual package over PvGRUB.
Sure, but let that happen first and then depend on it.

I'll add an adjusted change that just adds the |ovn-host.

Hans