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
