On 29/1/22 13:12, Felix Yan via arch-dev-public wrote:
On 1/29/22 02:12, Allan McRae via arch-dev-public wrote:
The decision to be made is who will package for this repo? I think these are the options:
A) packagers upload both x86_64 and x86_64_v3 to the repos. Our build server will help those without x86_64_v3 machines.
B) we recruit some packagers to build the x86_64_v3 packages.
C) Some combination of A+B.
My understanding is our x86_64 port started with B, then C, then A.
I am fine with either and could happily help with B in long term.
For me the issue with either B or C is that our packages are often FTBFS and we are slow to fix them, generally. To make the port really usable for a B/C workflow, we need a way to fill in the time gap (because the old package could be unusable for the time, like missing a so-name bump etc).
Do you find it acceptable if the x86_64_v3 rebuilders put back in the new x86_64 package until the build was fixed and probably a point pkgrel was added for the real x86_64_v3 rebuild, as long as we use B/C to build for x86_64_v3, in the long term?
I envisioned the x86_64_v3 repos were initially seeded with x86_64 packages. Then x86_64_v3 packages gradually replaced them as updates/rebuilds happen in x86_64. FTBFS for new packages should be less of an issue as long as the two repos do not get out of sync for long - I was considering the i686/x86_64 days where the sync with i686 was within days if not hours. But yes, a workaround could be adding x86_64 packages into x86_64_v3 if really needed. I'm not sure the workflow for doing that in terms of devtools/dbscripts. Allan