Hi, On Thu, Dec 11, 2014 at 06:08:58PM +0000, Leif Lindholm wrote: > When working on UEFI kernel support, for both armhf and arm64, we came > across packages (in several distributions) that were manually set to > build for architectures where UEFI was available - and so would not be > built for the ARM architectures. > > These are some obvious utilites such as: > - efibootmgr > - efivar/libefivar > - future versions of gnu-efi (upstream support for arm* has not > trickled back down yet) > > But also installer-specific ones like: > - partman-efi > > And some weakly related-to, but not really part of: > - dmidecode > > ... and definitely other ones I haven't come across yet. > > The point is, when we add support for another architecture which > supports UEFI, there are a number of packages that you will want to > enable for that architecture. Currently, this means trawling through > all of the packages and explicitly adding entries for > If we could transition this to be able to specify efi-all (or > whatever) instead of an explicit list of certain architectures, this > would be a lot more straightforward operation. > > Most, if not all, of these tools use only standard posix interfaces, > so will build cleanly for any architecture. > > An alternative would of course be to simply do like with acpica-tools, > and build all of these tools for all architectures. The problem there > would be with packages which depend on packages that only exist on > architectures that have UEFI - i.e. partman-efi vs. efi-modules. > > Would this be useful, desirable, an accident waiting to happen?
How about building for "arch: any" and adding a build dependency on a new "efi-support" package, that is only available for architectures with efi available? -- Sebastian
signature.asc
Description: Digital signature
