Re: Can/should we have an efi/efi-any platform architecture?
+++ Jonas Smedegaard [2014-12-11 21:38 +0100]:
> Quoting Neil Williams (2014-12-11 21:07:15)
> > On Thu, 11 Dec 2014 19:36:19 +0100
> > Simon Richter <sjr@debian.org> wrote:
> >> On 11.12.2014 19:08, Leif Lindholm wrote:
> >>
> >>> 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.
> >>
> >> Useful, possibly, but there is no mechanism that could be used or
> >> recycled for that, so it would be an entirely new mechanism in the
> >> package management framework, with a fairly limited use case.
> >
> > There is an accepted mechanism: linux-any is a group of architectures
> > which have one set of packages in common and we have had others.
> > efi-any would seem to be entirely possible without implementing
> > something completely new. It would need dpkg and buildd support. With
> > linux-any it relies on a list of architectures in a table in dpkg -
> > the same could be done for other groups.
>
> Elegant!
This was the mechanism the original mail was intended to consider. (We
already discussed this in the office). The question is: is a simple
grouping of existing architecture sufficient for this sort of case.
Support for this is just added in dpkg - that's very simple. I guess
some other things like lintian would need to know about it being a
valid value.
The effect of marking a package efi-any is that it is always built on
the architectures so-marked. That means that it is available on those
arches, for hardware that supports efi.
The tricky bits comes around the fact that at any given time some
hardware in an arch is efi, some is not. So building the package on
those arches (and marking it 'efi-any') does not mean that efi is
always available, on a given machine, just that it might be. This has
been the case in x86 (and presumably other arches) for a long time and
works fine.
I _think_ this is absolutely fine, and actually this mechanism fits
very well for this purpose. But it is still a new usage of our
'arch-grouping' mechanism, and some thought about what might go wrong
is in order.
The alternative to having this sort of 'sub-platform available on this
arch' name is to manage the arches manually in all the affected
packages, which is mostly a porter job (rather than a maintainer job)
as they know when efi appears on new arches. That's clearly do-able,
having been the mechanism to-date. And it remains an option as
packages can still give an explicit list if they like - they don't
_have_ to declare 'I should build on everything 'efi-any'.
Putting this info in dpkg means that it can only be updated quite
slowly, but new efi arches do not come along very often, so I think
that will work OK in practice.
So I am a little wary, but I _think_ this makes quite a lot of sense.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
Reply to: