On Wed, Apr 6, 2016 at 12:09 PM, Lamar Owen <[log in to unmask]> wrote:
> On 04/05/2016 06:34 PM, Yasha Karant wrote:
>>
>> Note that, unlike ELRepo folks with whom one can communicate via the SL
>> list (persons who even are willing to identify themselves, and not "hide"
>> behind some Bugzilla-like interface), EPEL seems much more unwilling to
>> discuss matters. Has an EPEL "maintainer" ever (recently) posted/replied to
>> the SL liist? I fully understand that the ELRepo folks are (presumably)
>> volunteers, and thus may have little real free time to address such issues;
>> hence, one should not pester them, particularly from typical enthusiast
>> "users". I suspect that EPEL persons in part may, as with CentOS, now be
>> paid by Red Hat, but I do not know this for a fact. ...
>
>
> EPEL is essentially Fedora on a project level; it's basically 'the Fedora
> packages that can be packaged for various RHEL-derived distributions
> packaged for those distributions.'  It's also typically (but not always) the
> Fedora package maintainer maintaining the EPEL package, and it is most
> useful to contact that person directly.  Bugzilla is the preferred means of
> contact, since it tracks the issues in a far more accessible (to the
> packager) way; no one is 'hiding' behind BZ, it's just the preferred way to
> get issues reported, tracked, and addressed.  Discussion of the base
> packages would likely be on the fedora-devel list, since EPEL is something
> of a Fedora thing.  Smooge, please feel free to correct my inaccuracies
> there, since you are connected directly to that and I am not.

There are some critical differences. EPEL never, never, never provides
a direct replacement or update to a base RHEL, and thus to a base
Scientific Linux package. I publish a *lot* of backported versions of
SRPM's to enable components for producton RHEL, CentOS, and Scientific
Linux environments. They do publish some parallel versions of packages
with alternative but compatible package names, and these can be
useful. But burden of backporting components that would require
updating system libraries winds up in the hand of individual
contributors, especially since RPMforge has effectively become
moribund. Many of them have been invaluable: "git" for RHEL or
Scientific Linux 5, for example, has been my friend.