On Mon, Oct 31, 2016 at 12:11:31PM +0100, Alexander Kurtz wrote:
> This becomes even more important if you try to fix #842683 [1], so I
> propose a scheme looking something like this:
>
> * There is only one arch:all package called "ovmf" containing the
> builds for all architectures.
>
> * The actual firmware files could be named like this:
>
> /usr/share/ovmf/$arch.$type
>
> where $arch would be the UEFI-style architecture name in lower
> case, i.e. "ia32", "x64", "ia64", "arm", "aa64" [2] and $type
> would be one of "code", "vars", "unified" (for the deprecated
> variant with code and vars in one file).
>
> * Compatibility is ensured by providing a transitional qemu-efi
> package depending on the ovmf package and the ovmf package
> carrying symlinks for all previously used file paths.
>
> What do you think?
Alexander,
Thanks for starting this discussion. I agree that the current scheme
needs improvement. I think package names, file paths, and grouping are
all fairly independent topics, so I'll address each one separately,
starting with package names.
My reasons for choosing "qemu-efi" when adding the aa64 images were
twofold:
1) "OVMF", in upstream source, refers only to the x86-specific
build. The ARM images have always had a different name - initially
ArmVirtualizationQemu, and currently ArmVirt.
2) "OVMF" doesn't seem like a keyword users would likely be familiar
with. I'd expect a user to know they want "EFI" or "UEFI" for use
with QEMU. OVMF, IMO, is yet another obscure term in the soup of
names here (edk2, EFI, UEFI, Tianocore, OVMF).
Therefore, if we're going to try for more consistent package naming, I
think I'd rather not consolidate under "ovmf". Since, AFAIK, these
images are only useful for QEMU models, I'd rather go the other way
and use the "qemu-efi" stem instead of "ovmf", e.g.:
qemu-efi-{aa32,aa64,ia32,x64}-virt
As for file paths, we're currently using the paths that libvirt and
OpenStack nova default to. We could move everything and provide
symlinks for compat, but I'm not convinced this is a big enough
problem to do so - in fact, I think that would only add confusion.
That said, libvirt/OpenStack don't appear to have unique paths defined
for 32-bit variants, so I'm not sure what to do for those.
Finally, regarding package grouping, I do think we want to retain
the ability to install the firmware for each architecture
independently - similar to how it is possible to install
qemu-system-<arch> packages independently. I suspect that most users
really just require one of them, and combining them all would make a
very large package (qemu-efi's Installed-Size alone is currently
129M). If there's a good use case for a meta package that installs all
of them, I'd be +1 for that.
-dann
