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. > 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. Above I've identified the real risk of leaving duplicates active in EPEL. Both the letter and the spirit of our guidelines are to not override RHEL packages. That is what I'm focused on. Please don't assume anything beyond that. > 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 -- Carl George _______________________________________________ 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
