Leif Lindholm <leif.lindholm@linaro.org> (2014-12-11): > 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. I can understand the feeling, having done such things in different areas (non-Linux porting, I was young…), but it seems to me the best way to deal with that is to just list the relevant packages on some wiki page. It's not like we're adding new architectures every month, and some one-shot updates of well-known components shouldn't be too much of a hassle. You're likely going to need and double check there's no missing arch-specific bits anyway, see 2c62dc1542bb8d67da97de40a5d9c7da645fa498 in grub-installer for a random example. So said wiki page would probably benefit from some per-package “how to add support for a new arch” instructions. > 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. efi-modules (is virtual but anyway) is section: debian-installer, so is in another part of the repository, that wanna-build and friends doesn't known about (at least that'd be my guess). Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature