Re: Timeframe for EPEL retirement vs RHEL new package releases

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 17.03.23 um 11:17 schrieb Carl George:
On Wed, Mar 8, 2023 at 9:43 AM Troy Dawson <tdawson@xxxxxxxxxx> wrote:



On Wed, Mar 8, 2023 at 6:31 AM Troy Dawson <tdawson@xxxxxxxxxx> wrote:

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

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.


IMO, would Epoch: in the RHEL package not help here?

--
Leon
_______________________________________________
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




[Index of Archives]     [Fedora Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Announce]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux