nagios shipped by RedHat, but in a specific subscription channel

Christopher chrismcc at pricegrabber.com
Tue Jan 12 17:41:00 UTC 2010


On Tue, 2010-01-12 at 10:00 -0700, Stephen John Smoogen wrote:

<snip>

> Ok this is the problem with strict policies versus writing to intention:
> 
> If Red Hat were to mirror everything in EPEL as a channel called
> "Unsupported Community Packages from EPEL" our logical conclusion
> would be to remove all those packages from EPEL... which would remove
> them from that channel, which means we could add packages back to EPEL
> which would...
> 
> So what is the intention that we are wanting? And can we write to
> that. Here is a list of things that come to mind in no meant order.
> 
> 1) We do not wish to replace or conflict with the channels from a Base
> install. [EG if its on the DVD RHEL provides we don't replace or
> conflict.]
> 2) We do not know what is in all the other RHN channels. We do not
> know what will be in an update either.
> 3) Red Hat people would like that their 'free' versions of packages
> were in EPEL (the spacewalk people would like spacewalk, the 389
> people would like 389, etc) as it allows them to push newer packages
> to people who are testing them in real environments.


Possibly RH could use a one-higher Epoch in their channels.  Everybody
wins.



> 4) However inclusion of this will cause problems with other RH products.
> 
> So how should we word it to best work out intention, should we look at
> our own layering of stuff, or something else... and whatever we decide
> lets do it.. this seems like the 8th time this discussion has come up.
> 
> 


-- 
Christopher McCrory
 "The guy that keeps the servers running"
 
chrismcc at pricegrabber.com
 http://www.pricegrabber.com
 
Let's face it, there's no Hollow Earth, no robots, and
no 'mute rays.' And even if there were, waxed paper is
no defense.  I tried it.  Only tinfoil works.





More information about the epel-devel-list mailing list