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