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.
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@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
