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

[Filipe Laíns]

On Wed, 2021-03-03 at 21:11 +1000, Allan McRae via arch-dev-public wrote:
> On 3/3/21 9:00 pm, Filipe Laíns wrote:
> > On Wed, 2021-03-03 at 20:52 +1000, Allan McRae via arch-dev-public wrote:
> > > 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.
> > 
> 
> The mirror in our mirrorlist file use "$arch" which pacman replaces with
> the architecture of what it needs to download.  Without a complete port,
> that value would remain as x86_64.  So now you need to put each mirror
> in the mirrorlist file twice (one with x86_64-v2 and one with x86_64),
> and you would have to assume they stayed in sync or risk partial updates.
> 
> I think a partial port would require more effort in the long run than a
> complete one.  And if we can do x86_64-v2, we might as well do -v3 too.
> 
> Allan

Well, pacman could change the behavior here and instead of simply replacing the
variable and declaring one sever entry, it could take raw string, evaluate it as
each $arch and save the URL for each variant.

What I am proposing is to essentially split core.db into one database for each
arch.

So, let's say the enabled arch are any, x86_64 and x86_64-v2. Then

Server = https://mirror/$repo/os/$arch

would register the following DBs.

https://mirror/core/os/any/core.db
https://mirror/core/os/x86_64/core.db
https://mirror/core/os/x86_64-v2/core.db

x86_64-v2 would have precedence over x86_64, if there is a package there, it
would be used, if not then x86_64 would be checked.

A full port would introduce a lot of more effort into the packaging workflow.
Personally, I maintain a lot of packages and would definitely be affected, this
would have an heavy impact my productivity.

My proposal allows me to for eg. only do arch=(x86_64 x86_64-v2) in srslte in
similar packages, keeping arch=(x86_64) in the rest.

Does that make sense to you? :)

I think the main counterargument I see for this proposal is the splitting of
databases maybe slowing down sync a bit, but honestly, do we really care about
that amount of performance hit? And wouldn't that be mitigated with parallel
downloads?

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