Re: Freestanding arch

[Guillem Jover <guillem@debian.org>]

Hi!

On Sun, 2024-11-24 at 16:09:42 +0000, Bastien Roucariès wrote:
> Le dimanche 24 novembre 2024, 12:06:26 UTC Bastien Roucariès a écrit :
> > I plan to implement freestanding architecture specification.
> > Following Toulouse debian mini debconf and javascript presentation it will be really helpful as a first step
> > 
> > https://wiki.debian.org/Teams/Dpkg/Spec/FreestandingArches
> > 
> > First likley to be implemented will be UEFI arch.
> > 
> > Any pointer for dpkg code to modify/test will be helpful.

I've had the following branch for a while:

 <https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/commit/?h=pu/arch-none>

The main problem is that the «none» part involves both a bit weird or
unexpected semantics, and to add support for it, would imply modifying
not only all currently known code handling build dependencies and
architecture fields from debian/control, but also the magic run-time
matching from the base arches to their «none» compatible counterparts
(with implicit arch tuples; and thus expose their internal representation
to layers that have not had to care at all about this).

The weird/unexpected semantics are related to the fact that «any» will
currently match «none», so this cannot even be used right now, as you'd
get a full arch with the none-arch buildds trying to build pretty much
the whole distribution, and not being able to discern what is
specifically relevant. Then, if we managed to change every arch
comparators, there's the problem that then «any» no longer would match
_any_ arch value, which seems strange to me. I mean we have the «all»
arch which is similar in the sense that «any» does not match it, so I
guess it could be thought in similar terms. Or there could be the
alternative though, to extend our handling of «all» to make it more
fine grained, so we could have:

  all-amd64
  linux-all
  musl-all-all

(AFAIR this has been brought up in the past, but I don't have references
at hand and I cannot recall who proposed this first, whether it was me,
perhaps Paul Wise, or someone else?)

This might perhaps(?) be less confusing than using «none», and
certainly more generic and probably more useful for more things, but it
would still imply several of the problems mentioned above.

In the end, while something like this could be implemented, as I
mentioned last time you asked, IMO this needs to be discussed first with
the various infrastructure teams, and whether they could see something
like this being supported (say in the archive adding the partial repos
for these arches, in d-i by adding these as part of the installation,
as part of the release process to handle potential cross arch
dependencies, etc), otherwise, while I think in an ideal world it might
be nice to have support for it, it would be kind of a wasted effort.
And in general terms we should also be thinking what are the actual
benefits, compared to the amount of work and infrastructure and
documentation changes that this might imply.

I think adding this to the GNU config project might have similar
consequences with how GNU triplets might get matched and normalized?
And AFAIR, GNU config does not even have a concept of something like
«none» or «all».

> > for adding uefi triplet (https://wiki.debian.org/Teams/Dpkg/FAQ#Q._Can_we_add_support_for_new_dpkg_architectures.3F)
> > - UEFI was added to config
> > - binutils status and gcc is for me unknown. Help welcome here (dokko, skitt ?)

I think it depends how this would look like, but in general I think if
we consider UEFI as a sort of an OS with a specified ABI, then this
seems less of a «none»/generalized-«all» arch, and adding it would have
similar problems with how to decide not to build for such UEFI buildd.

> This the patch I plan to debian arch

Adding the definitions has never really been the problem. The problem
is finding semantics that make sense and do not have weird/unexpected
behavior, and I guess ideally that do not require modifying the entire
build dependency parsing code around nor architecture handling in all
the relevant projects (but perhaps this last point is not possible to
avoid).

Thanks,
Guillem