On Tue, Mar 7, 2023 at 7:16 PM Carl George <carl@xxxxxxxxxx> wrote:
On Tue, Mar 7, 2023 at 2:18 PM Troy Dawson <tdawson@xxxxxxxxxx> wrote:
>
>
>
> On Tue, Mar 7, 2023 at 11:38 AM Carl George <carl@xxxxxxxxxx> wrote:
>>
>> On Tue, Mar 7, 2023 at 8:52 AM Troy Dawson <tdawson@xxxxxxxxxx> wrote:
>> >
>> > On Mon, Mar 6, 2023 at 8:48 PM Carl George <carl@xxxxxxxxxx> wrote:
>> >>
>> >> On Fri, Mar 3, 2023 at 5:42 AM Daniel P. Berrangé <berrange@xxxxxxxxxx> 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@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, report it: https://pagure.io/fedora-infrastructure/new_issue
