Re: EOL for EPEL

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

 





On 22 September 2017 at 15:21, Stephen John Smoogen <smooge@xxxxxxxxx> wrote:
On 22 September 2017 at 07:28, Somers-Harris, David | David | OPS
<david.somers-harris@rakuten.com> wrote:
> Hello,
>
>
>
> It is my understanding that the EOL for each EPEL is in line with RHEL.
>
>

1. The EOL of any EPEL repository is the "public" lifetime of an
upstream Red Hat Enterprise Linux. Public currently means when a RHEL
is in Production Level 1,2 or 3. It does not cover when the product is
in what is currently known as Extended User Support. [I use currently
because this email may be read 4-10 years from now and those terms may
have been relabeled.]

2. The EOL of a package in an EPEL repository is set by the
maintainer(s) of that package. They can orphan or remove a package at
their discretion and the package will be removed soon afterwords.

https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux
https://access.redhat.com/solutions/690063



To make this a little clearer, and highlight some of the limitations we face as packagers maintaining things in EPEL, I had to EOL owncloud in EPEL6 a year (ish) back as the version of PHP that was shipped was too old to support the application ... even though upstream or alternate repos like remirepo can still support the package and maintain it on EL6 as they use stuff like SCL to have the newer PHP version.

Similarly very soon (weeks or month or two at most) I'll be retiring owncloud and nextcloud from EPEL7 as it's no longer possible for me to maintain it there, though using upstream or alternate repos would still be an option.

Since EPEL is a volunteer effort for any packages you really care about it's important to mirror locally so you can rebuild systems safely, and we value help in testing where we've carried out maintainer patches to handle the package on something that is otherwise generally unsupported upstream (I did this for sslh on EPEL5 for a while for instance)... it's also best effort so please pay attention and file bugs where maintainers don't notice an upstream release or where there is a need to formally retire for the sake of security etc when it can no longer be built on the older systems.

_______________________________________________
epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx

[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