On Tue, Mar 7, 2023 at 11:38 AM Carl George <c...@redhat.com> wrote:
> 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). We already know this isn't true. We've had packagers accidentally retire packages early and people get hit literally the next day. > 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. > RHEL has been very good (lately) about their NVR's being higher than EPEL's. If that is so, the EPEL packages don't take precedence over RHEL's. I don't see the need for a rush. You seem like you are going for the letter of the principle instead of the spirit of the principle. We know that the majority of our users are not RHEL users, they are clone users. I see no reason to irritate the majority of our users just because we want to "minimize delay". 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
