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

[Allan McRae]

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:
>> 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.
> 

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