On Tue, 7 May 2024 at 01:20, Guillem Jover <guil...@debian.org> wrote:
> 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. > I think I agree although I would probably phrase it a bit the other way around. The facility we are talking about adding here technically speaking /could/ apply to any compiler settings that do not affect ABI, but /should/ it? The motivation behind different -march flags seems sound. There are some other things we could technically do that just seem like a bad idea (like a variant built without hardening flags). I don't think having a variant with -O3 makes sense -- I think it is the role of the distro to evaluate which of -O2 and -O3 is better and not just punt that sort of thing to the user. So I think a tighter target scope is best and if the naming of fields can point in that direction it's probably a good thing? As much as ArchitectureISA doesn't seem particularly aesthetic to me. OTOH, something like this might be useful for experimentation, to be able to spin up a variant as part of finding out if -O3 is better. We have other ways to do this for Ubuntu but they are annoying and clunky. Cheers, mwh
