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

[Hans van Kranenburg]

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