Re: Freestanding arch

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
311dxxoty5QgXwFoAdqiALD2NFAdH+GCqdVyG8aydrje0F09/Yio4lZFE4NCppLP
FtPbFDCflUIP7TU1L9PS7+IaX/lhScyHUeqbkNcN1IYm0c7cFO79zwzDehj3PpPI
yffgnw+iQd68bDHlhyIlJgq7uzrgAbQMX57BEI4Xug7MP4vXxAYU0yyVGWCEI3tg
TFNUw1HHvXWwZIEDT5iUEVn5yT1bGz7h18UrTNEkr1TT6gr+6EI8hCOY65FnDykY
xJWJACNnWjW+s0sSIX/G4vQA+6XffDfwFP2UE1vhEh064+biGNpJJCHIKSfw60Yc
siaHj9Fg3tb5jH0dtn4DlKHq/x24CkG12OTYvXqFGhzODiratdnkoKdTLphWwPao
V8+U8rd80H3enblEEGufsKrg6yjiYguryCmXHKM0C+RxWNIZRwkByDnQaKp2RT90
FRbSA20A1csZAa056skcseMt3v6bdlLF2kaOC/aREpAfNbMU++hQTtEOvUaSKhao
og//Xr9hNyGOTgo5RriHxQ7LtepAJrBUE1/1OD1pxnB0L4fTDLY=
=/Vot
-----END PGP SIGNATURE-----