FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > EPEL Development

 
 
LinkBack Thread Tools
 
Old 07-28-2011, 04:28 PM
Todd Zullinger
 
Default EPEL conflicts with RHEL channels (was: Possible new maintainer)

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? 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. But if
there are ways we can help alleviate issues for MRG users, I'm game to
try.

--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
After all, there is no position so absurd that you cannot get a great
many people to assume it.
-- Gore Vidal

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 07-29-2011, 08:42 AM
David Juran
 
Default EPEL conflicts with RHEL channels (was: Possible new maintainer)

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
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 07-29-2011, 08:46 AM
David Juran
 
Default EPEL conflicts with RHEL channels (was: Possible new maintainer)

On Fri, 2011-07-29 at 10:04 +0200, Matthias Saou wrote:
> Todd Zullinger wrote :
>
> > David, do you know if the MRG folks have issues with facter and puppet
> > in EPEL? 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. But if
> > there are ways we can help alleviate issues for MRG users, I'm game to
> > try.
>
> I seriously hope MRG will be ignored here : No one using puppet today
> will be interested in the old packages it ships, and as you mentioned in
> another post, upstream is *very* active and many people are tracking
> the releases very closely (me included).

Well, there's always is the possibility of doing various packaging magic
that would allow parallel install or at least cause a package conflict
which would prevent accidental upgrade. But as I mentioned in my
previous email, not sure if there is much point in doing this for this
particular case any more.

--
David Juran
Sr. Consultant
Red Hat
+358-504-146348
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 07-29-2011, 06:17 PM
Stephen John Smoogen
 
Default EPEL conflicts with RHEL channels (was: Possible new maintainer)

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 

Thread Tools




All times are GMT. The time now is 05:23 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org