XPost: linux.debian.devel
From: [email protected]

Le mardi 26 novembre 2024, 00:29:40 UTC Guillem Jover a écrit :

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?)

I think here debusine will help.

None will be a special case of all

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.

Yes it is a chicken and egg problem.

Debusine team might help but it need dpkg support,so we must begin by something

I think adding this to the GNU config project might have similar
consequences with how GNU triplets might get matched and normalized?

Last config was adding none with wit arch and ABI so
x86_64-unknown-none-elf was a perfect archit triplet

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.

Yes but the freestanding arch is a first step toward cross build partial arch

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

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEXQGHuUCiRbrXsPVqADoaLapBCF8FAmdFnsIACgkQADoaLapB CF++UxAAojhOanjMmWhhoDHyWwwUY0VPlEvcsh/bZNjwLqJrJVYHtzOnfwsdONhn M/wICo7nbIQ6pK3mXLxPfVUbWLeCm02Bt/9g3kDWQVESlGkzWw2iEBqcip51iuG3

[continued in next message]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)