On 22 September 2017 at 15:21, Stephen John Smoogen <smooge(a)gmail.com>
On 22 September 2017 at 07:28, Somers-Harris, David | David | OPS
> 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.
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
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.