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

[Filipe Laíns]

On Wed, 2021-03-03 at 20:52 +1000, Allan McRae via arch-dev-public wrote:
> On 3/3/21 8:32 pm, Filipe Laíns wrote:
> > 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...
> > 
> 
> I'd hate to be the dbscripts maintainer who implements that!  Also,
> $arch in mirror URLs would likely have issues, as it would need be
> x86_64 unless there was a complete x86_64-v2 build.
> 
> I think a partial x86_64-v2 port would be more effort than having a full
> one.
> 
> Allan

We are already rewriting dbscripts for the git migration anyway, so I think it's
worth exploring.
Why would the mirror URLs be an issue if we are using $arch as a placeholder?

Sorry if I wasn't clear, but I meant that we would have a partial port! pacman
would download all the DBs for the supported archs, hence my question about the
DBs. It would look at x86_64-v2 first and if the package wasn't there, it would
then look at x86_64. Makes sense?
This could cause some breakage, but we work around that.

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/bf37b640/attachment.sig>