Re: Architecture variants for Debian / Ubuntu

On Tue, 7 May 2024 at 01:20, Guillem Jover <[email protected]> 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