On Fri, Jul 29, 2011 at 02:42, David Juran <djuran(a)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.htm...
>
> 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(a)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