On Tue, Mar 7, 2023 at 7:16 PM Carl George <c...@redhat.com> wrote:
> On Tue, Mar 7, 2023 at 2:18 PM Troy Dawson <tdaw...@redhat.com> wrote: > > > > > > > > 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. > > Got any examples of this "next day" timing? The problem in the > bugzilla linked at the start of this thread was that the retirement > took place long before the package was in RHEL. I don't see any > mention in the bug of observing the lack of the package on the > mirrors, just discussion spurred by the maintainer commenting that he > performed the retirement. Anecdotally I recall there being at least > several days delay between retirement and the rare complaints about > the package not being available in EPEL anymore. If users are > consistently seeing the effects of a retirement the next day, then of > course waiting a little bit longer could make sense. > > > > > > >> > >> 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. > > They may not when you first check. The risk in leaving the branch > active is that a maintainer may bump the version and/or release and > start overriding the RHEL package at any given time. We don't > currently have a mechanism to freeze the distgit branch but leave the > package in the repo. Our current calculus is "if the package is in > RHEL, it needs to be promptly retired from EPEL". Leaving packages > longer means that someone needs to continually check that the > duplicating packages haven't started overriding their RHEL equivalent. > Before I dig through all my emails, let me ask if you have got any examples of EPEL packagers updating a package after RHEL has released it? (Within a reasonable time frame, which is to say a month after the release) Beyond the reasoning about timing, here's my other problem. In the script I'm writing, I can't check if a package has been released by RHEL, I can only check if a package has been released by Alma and/or Rocky. It's the same reason that willit is only checking against Alma. The whole subscription problem. 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
