On Sat, 2024-05-04 at 01:07:59 +0200, Matthias Klose wrote: > On 03.05.24 11:27, Julian Andres Klode wrote: > > On Wed, Sep 06, 2023 at 11:27:02AM +0200, Guillem Jover wrote: > > > Some of the above problems could perhaps be avoided if we introduced > > > a concept of architecture aliases/ISAs (similar to what rpm has), which > > > would side-step the pool sharing issue, the binary package renaming, > > > etc. One big issue with this is that it requires for dpkg to have an > > > exhaustive table of all such aliases, and if there's ever a new alias > > > added, old dpkg versions need to be updated or they will not understand > > > what they match with. So this does not seem ideal either. So I guess this > > > is a variation over your proposal, but perhaps this could still be used > > > in specific contexts, say only at build-time (but not for dependency > > > relationships), for repo management (say binary-arm64v9/Packages.xz), > > > or binary package names where the field would specify the actual name > > > for the filename, say: > > > > > > Architecture: arm64 > > > ArchitectureIsa: arm64v9 > > > > > > or maybe better: > > > > > > Architecture: arm64 > > > ArchitectureIsa: v9 > > > > > > resulting in dpkg-deb generating: > > > > > > binpkg_1.0-1_arm64v9.deb > > > > > > but targeting arm64. I also think I prefer naming this explicitly as ISA > > > variants, if you will, than just architecture variants as that gives > > > way too much room (which perhaps we want, but then that has other > > > implications over compatibility), and for the field perhaps just Isa is > > > better, to avoid the implicit repetition of > > > ArchitectureInstructionSetArchitecture :), but that makes it less easy > > > to associate both as related. > > > > I have thought more about this and I'm not particularly fond of the > > ArchitectureIsa name. While *this specific use case* is a variant of > > the architecture instruction set; you could just as well build other > > variants such as "compiled with -O3", "compiled with frame pointers", > > "compiled with -O0", or other shenanigans (I haven't thought about > > others outside compiler flags)
These looks really out of scope for the initially proposed purpose, as they have nothing to do with the architecture, they are rebuilds with different compilation flags. Creating a new pseudo-architecture for those things seems just wrong and out of place. I understand that might seem convenient, but it does not make sense to me, conceptually and from a design PoV. > or > - DistroBuiltWithClang, e.g. using libc++ instead of libstdc++. > - distro built with some of the sanitizers turned on by default These should already either be tracked as part of dependencies, or be potentially ABI incompatible (AFAIUI for some sanitizers) which would require a new arch and triplet anyway. > > Hence I prefer Architecture-Variant, Subarchitecture, or anything > > like that rather than have to invent another field or abuse this > > one the next time we want to build a special variant of an architecture > > with special optimizations for a special customer or whatnot. > > yes, it sounds like a bit too specific. It seems as specific as it needs to be, TBH. The other proposed users do not really fit with the way this is supposed to be used. Regards, Guillem
