[CentOS-devel] Request for epel-release package in CentOS repo

On Fri, Apr 25, 2014 at 7:41 AM, Johnny Hughes <johnny at centos.org> wrote:
>
> Well ... my opinion is this:
>
> Just because the release RPM is in extras does not mean that people have
> to (or will) install it.  People have to "yum install epel-release"
> before they get access to the repo.

Yes, I agree that having to type
yum install epel-release
instead of, say
yum install http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
is a slight improvement, but not exactly world-changing.  If you know
to do one of those things you would probably figure out the other.
But, it doesn't solve the bigger issue.

> I would assume if someone wanted to install the epel-release package,
> the majority of them would want at least the main binary repository to
> be enabled by default.

That's probably what people think they want anyway.  But it can be
complicated, particularly when EPEL adds content that you were
previously getting from a different repo.  My old poster child example
for this was viewvc which was in rpmforge long before epel, and when
epel added it, they used a higher version number and an incompatible
configuration.  So, no warnings, no conflicts, just a silently broken
package after an update.   You can blame that one one on using
rpmforge, but for something that hits a little closer to home, do you
know where your NX libs came from and when it changed?   Someone on
the freenx list claims that the switch to EPEL's version broke his
normal X operation by changing LD_LIBRARY_PATH to find the wrong
libX11.so.   (Not sure why he had an old copy under
/usr/lib64/nx/X11/, but it points out the potential for surprises from
an always-enabled EPEL).  Even though they claim to have a policy of
not conflicting with or replacing upstream packages, only RH base is
'upstream'.

> If someone wants EPEL installed and wants it instead off (I think by far
> the minority ... does someone disagree?), they can modify their .repo
> file manually to turn it off.

I was just hoping someone would come up with a  solution for the
bigger problem of uncoordinated repos.  Like making yum need an extra
option to make it take an update from a different repo than the
original install.  Or some external database that tracks conflicts and
duplicates across repos with different contents/policies. Or a way to
force packages from certain repos into a software-collections type
space even if they weren't built that way.

> That being the case, I would think the best thing is that we just build,
> sign, and push the current release file from the EPEL repo for c5 and c6
> in our CentOS Extras .. in the appropriate spot.
>
> Thoughts?

Doing that would not be a problem - but it doesn't solve the big problem either.

-- 
   Les Mikesell
     lesmikesell at gmail.com