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

[Stephen John Smoogen]

On Fri, Jul 29, 2011 at 02:42, David Juran <djuran at redhat.com> wrote:
> 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

A system administrator who uses MRG on a Grid and then pulls in EPEL
willy-nilly gets what is coming to him, mainly walked out the door.

> 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.

EPEL like any other add-on can not be guaranteed safe in any
environment any more than blindly updating from 5.n to 5.n+1 is
guaranteed to be safe (and if it is.. I need some rather large checks
from RH for overtime over the last 10 years :)). A system
administrator MUST take responsibility for the fact that software is
complicated and interactions between things are not always going to be
"safe". A system administrator MUST have a plan on how to locally
update, test, deploy en-mass, and back track.

[I am not saying this because I think you disagree, just stating some
facts that no software is safe, and there are no guarantees with EPEL.
We will do our best to make it work, but we can't stop stupid.]

>
>>  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
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list
>
>



-- 
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren