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