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? / Leif -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141211180858.gs2...@bivouac.eciton.net