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 > >
signature.asc
Description: This is a digitally signed message part.
