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