EPEL conflicts with RHEL channels (was: Possible new maintainer)

[David Juran]

On Thu, 2011-07-28 at 12:28 -0400, Todd Zullinger wrote:
> I wrote:
> > This might be the thread we were thinking about:
> >
> > https://www.redhat.com/archives/epel-devel-list/2010-December/msg00102.html
> >
> > That means that facter and puppet are violating this. :(
> >
> > They have been doing so for years.  I strongly suspect that they were
> > in EPEL before they got added to MRG and no one noticed at the time.
> > I started helping with the packages in Fedora/EPEL around the 0.24.6
> > timeframe, but they entered EPEL in July of 2006, it appears.
> 
> After talking a little in #epel, Kevin pointed out that EPEL has
> primarily agreed to not conflict with packages in RHEL AS, but not in
> various other add-on channels.
> 
> http://meetbot.fedoraproject.org/teams/epel/epel.2010-01-15-21.00.log.html#l-134
> 
> The caveat to this is that we'll consider requests from RHEL folks to
> no ship things.  Obviously, no one wants to cause problems.
> 
> David, do you know if the MRG folks have issues with facter and puppet
> in EPEL? 

Not speaking for the MRG team, I can still imagine a scenario where e.g.
facter gets updated "by accident" from EPEL on a Grid scheduler and that
this potentially could cause problems. All of this is of course slightly
hypothetical, I don't even know if an updated facter  is a problem or
not but just the fact that it hasn't been tested tend to make people
nervous when production systems are concerned. And if we (EPEL, Fedora
project) want to tout EPEL as "safe to use" on all RHEL systems
regardless of add-ons, then this is a problem. On the other hand, if the
ambition for EPEL to only be "safe" for RHEL users without add-ons, then
this should be made more clear on the EPEL landing page. Maybe even with
some conflicts added to the epel-release package to prevent someone from
activating it by mistake.


>  As I said, those packages have been in EPEL for years, so
> I'm not sure there's anything to be gained by trying to block them at
> this point.  We're already way past MRG in terms of NVR's. 

Agreed, not sure if there is any point in beating on a dead horse in
this particular case. Both puppet and facter only relate to RHEL5-based
MRG-Grid-1 and don't seem to be present in RHEL6-based MRG-grid-2. So if
there ever was any damage done, one can always hope that it's done by
now... 

>  But if
> there are ways we can help alleviate issues for MRG users, I'm game to
> try.

What I think we need is a solution to the general problem, that it's not
trivial for an EPEL maintainer to know whether his package stomps on a
RHEL package or not. Is anyone from Red Hat (Release Engineering?)
reading this list? Any thoughts on whether it would be possible to have
an automatically updated list of _all_ RPM NVR:s published? That would
certainly be a starting point...


-- 
David Juran
Sr. Consultant
Red Hat
+358-504-146348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20110729/f3608a2d/attachment.sig>