On Tue, Mar 7, 2023 at 8:52 AM Troy Dawson <tdaw...@redhat.com> wrote: > > On Mon, Mar 6, 2023 at 8:48 PM Carl George <c...@redhat.com> wrote: >> >> On Fri, Mar 3, 2023 at 5:42 AM Daniel P. Berrangé <berra...@redhat.com> >> wrote: >> > >> > >> > There is also the case of the RHEL rebuilds whose users consume EPEL >> > packages. Depending how quick they are, the rebuild distros might not >> > have their 9.2 rebuild ready for some days/weeks/months after RHEL-9.2 >> > is first available. My projects' upstream CI is all based on AlmaLinux >> > and I don't want to see it broken again by premature capstone retirement >> > from EPEL. >> >> Historically, when CentOS was a rebuild, many EPEL maintainers would >> wait for corresponding CentOS rebuild release before changing their >> EPEL packages to work on RHEL. This was true both for soname rebuilds >> and retirements. CentOS would usually take about a month to catch up >> to RHEL minor versions. The new rebuilds are doing much better in >> this area. Alma is routinely getting their minor versions out 1-2 >> days after RHEL. The other rebuilds aren't far behind. If we were to >> delay package retirements, I don't think it's necessary to delay for >> more than a few days. > > > Do you mean "a few days after both Alma and Rocky are up to the latest > release." or "a few days after RHEL is released."? > > If you mean "a few days after RHEL is released." then I have to disagree with > you. > It does no harm to leave the packages in EPEL for a few weeks/months. > It does harm to rip the packages out too early.
I do mean a few days after a RHEL release. Between the distgit retirement, compose, and mirror sync delay, the package doesn't become unavailable for nearly a business week (~5 days). Users that already have the package installed are unaffected. If a user is using a RHEL rebuild that hasn't got their release done yet by that point, the only effect is that the package is unavailable in the EPEL repo, but it's still available for manual download from Koji or the snapshot archives. Harm is far too strong a word for this. It's a temporary annoyance that can be resolved by several workarounds, including switching to a rebuild that gets releases done faster. It's important that EPEL packages don't take precedence over RHEL packages, and you said yourself it's too difficult to continuously monitor which packages are a lower NVR than their RHEL equivalent and allow them to stay longer. EPEL targets RHEL, and we should minimize any delay of correcting issues that violate the core principle of EPEL. This should all be much simpler in EPEL 10. Package retirement will be per-minor-release. We'll be able to actually follow the guidelines in CentOS Stream, retiring the package in that EPEL repo without affecting RHEL users. When a new RHEL minor version happens, they'll switch from an EPEL repo that has the package to an EPEL repo that doesn't have the package (but it will be available in RHEL at that point). Anyone using an older minor version (whether EUS, a manually pinned release, or a RHEL rebuild that is lagging) can explicitly point to the EPEL repo that matches their minor version by passing the `--releasever` flag to dnf with the appropriate value. > > Troy > > _______________________________________________ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Carl George _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
