On Fri, Mar 17, 2023 at 3:17 AM Carl George <c...@redhat.com> wrote:
> On Wed, Mar 8, 2023 at 9:43 AM Troy Dawson <tdaw...@redhat.com> wrote: > > > > > > > > On Wed, Mar 8, 2023 at 6:31 AM Troy Dawson <tdaw...@redhat.com> wrote: > >> > >> 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 > >>> > > >>> > 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) > > The most recent example I remember is python-sqlalchemy. It was > available in EPEL 9 at version 1.4.37. That same version was added to > CentOS Stream 9 in preparation to go into RHEL 9.1. The EPEL > maintainer didn't notice the retirement warning bug and continued to > update the package to newer versions in EPEL 9. It made it up to > version 1.4.44 before it was retired. That last update to 1.4.44 was > pushed to stable on 2022-11-23, eight days after the RHEL 9.1 release. > Anyone that had it installed previously won't get upgraded to the RHEL > 9.1 package which is still at version 1.4.37. Thankfully the RHEL > maintainer agreed to rebase it in RHEL 9.2 to eventually resolve the > upgrade path. > > https://bugzilla.redhat.com/show_bug.cgi?id=2098498 > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-cee8cb8dc1 > > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/KGKSCFABQE6MJ5F4RKR3HUXW73GGTSU6/ > https://bugzilla.redhat.com/show_bug.cgi?id=2152649 > > It's happened before, and I'd like to minimize the window where it can > happen again in the future. I understand wanting to be courteous to > rebuild users, but we need to find the right balance. > Ah, thanks. I had forgotten about that. > >> > >> 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. > >> > I still have the subscription problem for any true automation. Maybe since Alma and Rocky are getting so quick at new releases, it won't matter if we just keep checking them both and once one has the package we do the remove. Either way, this time (RHEL 9.2 / 8.8) will be manual. I'm hoping it will be "manually run the scripts", but depending on how much time I have, it still might be "manual manual" 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
