On Thu, 8 Jul 2021, Kevin Fenzi wrote:
On Wed, Jul 07, 2021 at 08:28:20PM -0400, Mohan Boddu wrote:
Hello all,
While we are already working on epel9-next enablement, there was a
discussion about how to handle epel9 when rhel9 goes GA. It is safe to
assume that a lot of the builds that are already in epel9-next at that
point of time should work on rhel9.
Yeah, a lot... but not all probibly.
There were couple of ideas thrown around from doing nothing to tagging
epel9-next builds to epel9, but I think the best way to solve this is,
mass branching the packages that have epel9-next branch and create
epel9 branch from it and then running a mass rebuild without any
changes to spec files. As epel9-next builds will already have a
.el9.next dist tag, we can simply rebuild whatever there is in epel9
branch (after branching epel9 branch from epel9-next branch).
Since the builds are done in alphanumerical order and does not
preserve build order, we might have to run this mass rebuild a few
times (thinking of 5 times) on the failed builds to get most of the
builds. This doesn't involve changing the spec files, just
resubmitting the failed tasks.
Well, it may be possible to just look at the failures after 2 passes and
see whats going on. I don't think we will have thousands of epel9-next
packages at that time, probibly hundreds? or even less.
Also, people who wish to opt out of this mass rebuild can add
'noautobuild' file to the epel9-next branch beforehand, this however
does not stop from creating the epel9 branch, just the package won't
be included in the rebuild. The idea here is, if the maintainer wishes
to support epel9-next, their final goal is to maintain the package for
epel9. So, we give them a branch, but will not rebuild their package
as they might have wanted to build their packages in the correct build
order (cough cough KDE :D).
This gives us a working epel9 with a bunch of working builds in a few
days after rhel9 GA and also we can create ftbfs bugs for those that
failed in the mass rebuild which will help maintainers to identify and
fix the issues.
Couple of questions that need to be answered here:
1. Is 5 times of rebuilds good enough or do we need more?
I think we should do 2 and then evaluate if more would help any.
Or I suppose we could go for 'steady state'. Ie, keep rebuilding only
the failures until the number of them is the same between runs. At that
point rebuilding them more won't help any.
Are we aiming for reproducibly built packages, like Debian
(I assume a completely reproducible *build* is still out of scope),
or is building every package on the new system sufficient ?
--
Andrew C. Aitchison Kendal, UK
andrew@xxxxxxxxxxxxxxx
_______________________________________________
epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
