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
