Re: pvgrub2 is merged

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 29.11.2013 14:24, Colin Watson wrote:
> On Sat, Nov 09, 2013 at 09:52:20PM +0100, Vladimir 'φ-coder/phcoder' 
> Serbinenko wrote:
>> Hello, all. pvgrub2 has just became part of upstream grub as ports
>> i386-xen and x86_64-xen.
> 
> Could anyone offer packaging advice for which ports should be built
> here?  Is it reasonable to assume that a 32-bit userspace only needs the
> 32-bit Xen port and a 64-bit userspace only needs the 64-bit Xen port,
> or is it possible that there could be cross-architecture combinations
> here?  Does the architecture of the GRUB port have to match the
> architecture of the Xen hypervisor?
> 
GRUB port has to match the architecture of domU kernel. This is
limitation of Xen architecture and it's one that is difficult to change
and it's unlikely to be.
But the architecture of Dom0 may be different from DomU one. Typically
grub-xen would installed on host and not guest.
Packaging should provide grub.xen standalone file. I intend to add
grub.xen compilation target to upstream once we gathered information on
what we put in grub.cfg there.
> For those familiar with Debian packaging, I'm trying to work out whether
> it's sufficient to just build grub-xen{,-bin,-dbg} packages which would
> be i386-xen on i386 and x86_64-xen on amd64, or whether I have to have
> two variants on each architecture the way I do for EFI.
We need 2 variants as it's common enouh to run 32-bit VMs on 64-bit host
and grub-xen is typically on host.
>  All other
> things being equal I'd prefer to keep the package count as low as
> possible, but only if that won't break real-world use cases.
> 
> Thanks,
>

signature.asc
Description: OpenPGP digital signature