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

[Allan McRae]

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