On 22 September 2017 at 15:21, Stephen John Smoogen <smo...@gmail.com> wrote:
> On 22 September 2017 at 07:28, Somers-Harris, David | David | OPS > <david.somers-har...@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@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
