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

[Allan McRae]

On 4/3/21 6:38 am, Filipe Laíns wrote:
> 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?

The exact same is achieved by having a "core-v2" and an "core" db, where
only the x86_64-v2 optimized packages appear in "core-v2".  But there
would need to be two separate package pools due to name clashes.  The
dbscripts maintainer has already said no to this.

Options realistically are:

1) bump the baseline
2) provide a second more optimized port.

Allan