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