[arch-dev-public] RFC: Use x86_64-v2 architecture

[Filipe Laíns]

On Wed, 2021-03-03 at 19:44 +1000, Allan McRae via arch-dev-public wrote:
> On 3/3/21 7:31 pm, Filipe Laíns wrote:
> > On Wed, 2021-03-03 at 12:12 +1000, Allan McRae via arch-dev-public wrote:
> > > On 3/3/21 11:56 am, Filipe Laíns wrote:
> > > > On Wed, 2021-03-03 at 11:10 +1000, Allan McRae via arch-dev-public
> > > > wrote:
> > > > > On 3/3/21 11:03 am, Eli Schwartz via arch-dev-public wrote:
> > > > > > I wonder, might this be an interesting time to reintroduce multiple
> > > > > > architectures?
> > > > > > 
> > > > > > We used to offer i686 and x86_64.
> > > > > > 
> > > > > > Maybe now we could offer x86_64, x86_64-v2, and x86_64-v3. Or go
> > > > > > right
> > > > > > to -v4.
> > > > > > 
> > > > > 
> > > > > That is a possibility that has been discussed over the years.  It was
> > > > > previously decided that we needed other architecture builds to be
> > > > > automated, and thus automated package signing.  This becomes a
> > > > > possibility once we manage to sign databases (which will hit a decade
> > > > > of
> > > > > pacman support in October!).
> > > > > 
> > > > > Allan
> > > > 
> > > > Is it possible to get pacman to allow us to enable multiple
> > > > architectures at
> > > > once and prioritize one of them? This way we could just do x86_64 and
> > > > the
> > > > maintainer could opt-in into x86_64-* if it makes sense for the package.
> > > > 
> > > > This would not introduce new effort to maintainers and would solve the
> > > > issue
> > > > quite nicely IMO.
> > > > 
> > > 
> > > No it is not possible in pacman (without abusing fall through when
> > > failing to download a package from a server).
> > 
> > Well, can we add it? What are the technical limitations here? I vaguely
> > remember
> > that package names colliding in the DB could be an issue, is there any way
> > we
> > can solve that? Do you have any suggestions on how this could be fixed?
> 
> 
> You would create "core-x86_64-v2" and "extra-x86_64-v2" repos that could
> be enabled above the current ones.  That would involve downloading twice
> the repos and figuring out our package pool (as you can not do that with
> different architecture strings).   Cleaner to have two separate
> architecture builds.
> 
> Allan

That is a reasonable enough approach, I think, though not optimal. I agree that
it would be better to have separate architecture builds. I'd also really like to
have this handled automatically by pacman, instead of having user having to
manually enable it.

Is there nothing we can do to fix the collision in the DB?

Right now, the DB is located at https://mirror/core/os/x86_64/core.db
Perhaps this does not make that much sense, but what about splitting the arch
DBs? https://mirror/core/os/{any,x86_64,x86_64-v2,...}/code.db
Does downloading the same data split across a few DBs take that much time? And
wouldn't this be mitigated by parallel downloads?
This is just me spit-balling...

Filipe Laíns
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20210303/162752c5/attachment.sig>