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

Hi,

On 1/2/21 9:30 PM, Elliott Mitchell wrote:
> Presently PyGRUB and PvGRUB are the DomU bootloaders available in
> Debian.  Several alternative DomU bootloaders exist, but are not yet
> available.  Add a recommendation of "xen-domu-bootloader" meant
to be
> provided by these options.
> 
> While the "traditional" Linux bridge has been favored for a long
time,
> presently Open vSwitch is gaining favor.  Add ovn-host as an alternative
> recommendation to bridge-utils.
> 
> Signed-off-by: Elliott Mitchell <ehem+debian at m5p.com>
> ---
>  debian/control | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/debian/control b/debian/control
> index 5e24f5fd3c..fc4523945c 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -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).

xen-domu-bootloader does not even exist as package. It does not make any
sense to add it.
>  Suggests: qemu-utils [i386 amd64], seabios [i386 amd64], ovmf
>  Description: XEN administrative tools
>   The userspace tools to manage a system virtualized through the XEN
virtual
Hans

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