On Tue, Mar 7, 2023 at 7:16 PM Carl George wrote:
> On Tue, Mar 7, 2023 at 2:18 PM Troy Dawson wrote:
> >
> >
> >
> > On Tue, Mar 7, 2023 at 11:38 AM Carl George wrote:
> >>
> >> On Tue, Mar 7, 2023 at 8:52 AM Troy Dawson wrote:
> >> >
> >> > On Mon, Mar 6, 2023 at 8:48 PM Carl George 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
