[arch-dev-public] Starting x86_64_v3 port

Allan McRae allan at archlinux.org
Sat Jan 29 12:53:41 UTC 2022

On 29/1/22 22:11, Morten Linderud via arch-dev-public wrote:
> On Sat, Jan 29, 2022 at 11:45:57AM +1000, Allan McRae via arch-dev-public wrote:
>> On 29/1/22 11:28, Morten Linderud via arch-dev-public wrote:
>>> On Sat, Jan 29, 2022 at 11:22:32AM +1000, Allan McRae via arch-dev-public wrote:
>>>> On 29/1/22 11:13, Morten Linderud via arch-dev-public wrote:
>>>>> On Sat, Jan 29, 2022 at 10:12:30AM +1000, Allan McRae via arch-dev-public wrote:
>>>>>> Is there any particular objection to requiring packagers upload both
>>>>>> architectures?
>>>>> I'm personally not really motivated doing the required builds. We have an
>>>>> underdeveloped infrastructure which hasn't changed since we abandoned i686 5
>>>>> years ago.
>>>>> I'd personally like to see more work on our build tooling before we commit to
>>>>> new architectures.
>>>> FYI, it is a single extra command.  Either of these will work...
>>>> offload-build --arch x86_64_v3
>>>> extra-x86_64_v3-build
>>>> Nothing else changes for the packager.
>>>> Allan
>>> I'll spend twice as long waiting for a package to build which increases the time
>>> spent packaging. Which again requires me to spend more time watching stuff fly
>>> by.
>> I have concerns if that is how you spend your time...  :)
> I have plenty time left over to ask for pacman backports :) DO NOT WORRY!
>>> This also assumes people are capable of using the buildserver which is not
>>> always the case either.
>>> This wasn't great with i686, and I'm not sure why we'd find this acceptable
>>> today?
>> What was not great with i686?  We managed two architectures for many, many
>> years.  The reason for removing i686 was to do with outdated technology, not
>> to do with build times or infrastructure.
>> Do you have objections beyond not wanting to package for both repos? i.e. do
>> you object to option C in my original email, where we have a team to keep
>> the repos in sync when package maintainers do not build both?
> I'm simply not sure where you are going to get the people for that and how you
> want to deal with it?

There is community demand for this port - it will provide benefit for 
the majority of our users.  I'm sure I can find interested parties to join.

> A *lot* has changed since the x86_64 port. Bringing on people to do these
> rebuild implies they need access to infrastructure, keyring and so on. And we
> already have a staff shortage.
> I'd like to see some details on how you envision C should be working first.

Exactly the same as it did in the i686/x86_64 days.  Some packagers will 
upload both variants, some will not.  There was a webpage that showed 
the package differences between the architectures and a group of people 
built and uploaded packages to keep x86_64 in sync.  This was 
particularly important when many devs did not have x86_64 hardware yet.

We may/will need to recruit some people to do these rebuilds.  The 
number of people needed depends on how many packagers would package for 
both architectures.

> Generally my thoughts is that we shouldn't *need* to have a more manhours to
> deal with a x86_64_v3. We should instead strenghten our staff and work on the
> following:
> * Signing enclave
> * Better rebuilding tools
> * Build automation
> * Git migration
> It would make discussions like these completely obsolete. Do we want v2, v3,
> v4, v5, v90001? Enable it in a setting and we'd have the repos. It is a lot of
> work but it would modernize and make things a lot simpler for us.

It has been over a decade since pacman allowed signing of repo 
databases, and we still have not managed to get those signed.  And a git 
migration has been discussed almost as long.  I don't think we should 
wait for this.

Though, given there is several years between hardware releases for each 
x86_64 version so far, we may be in that situation for automated builds 
by v90001!

But if developing this infrastructure does occur, everyone recruited for 
packaging x86_64_v3 will be able to help keep packages updated!  Win-win.


More information about the arch-dev-public mailing list