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

[Eli Schwartz]

On 3/2/21 9:12 PM, 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).

Right, we could have some packages built for arch=(x86_64) but with
optimizations and package them in a [community-optimized] repo or
something. This seems complicated and doesn't handle conflicting
filenames -- which is a serious problem for the server pool and archive.

Usually clashes would be eliminated by keying off of the architecture;
only one of each package per arch. This would not permit fallthrough though.

pacman could, theoretically, learn to support multiple "Architecture"s
in pacman.conf, e.g. configure it to support

Architecture = x86_64-v2 x86_64

and accept both types of packages. This would be needed in order to
support selectively optimizing packages while keeping the same pkgname.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20210302/85ae4f7d/attachment.sig>