nagios shipped by RedHat, but in a specific subscription channel

[Christopher]

Hello...


On Wed, 2010-01-13 at 17:54 -0600, inode0 wrote:
> On Wed, Jan 13, 2010 at 5:28 PM, Christopher <chrismcc at pricegrabber.com> wrote:
> > cost works in default RHEL5
> >
> > from man yum.conf
> >
> >  cost  relative  cost  of  accessing  this repository. Useful for
> >  weighing one repo's packages as  greater/less  than  any  other.
> >  defaults to 1000
> >
> > /etc/yum.repos.d/epel.repo could contain cost=1001
> >
> > yes? no? maybe?
> >
> > I use cost=100 so my local repo always wins against rhn
> 
> Does it really work? I honestly don't know but being in the yum docs
> isn't persuasive evidence that it will work against RHN channels which
> are not ordinary yum repositories. The yum-rhn-plugin has to support
> it for it to work with RHN and until very recently it supported pretty
> much nothing. I believe in 5.3 or thereabouts yum-rhn-plugin first
> allowed the ability to even specify enabled/disabled for individual
> RHN channels.
> 

It works in RHEL 5.4, I cannot test other versions.


> With RHEL5 people can always use includepkgs with EPEL so there does
> in fact exist a way to mitigate conflicts but ...
> 
> All these yum-based suggestions though leave me scratching my head a
> little. Let's stipulate for argument's sake that some yum dance would
> give us a way to work around conflicts. If I need to worry about
> conflicts and set up this or that to avoid them or mitigate danger,
> then I feel like I've lost one of the key selling features of EPEL. I
> do those dances for rpmforge, EPEL was supposed to make my life
> easier.
> 

Agreed.


> So I think the question just fundamentally comes down to do we want to
> avoid conflicts or do we want a really large and useful package set
> more. Good arguments can be made for both directions and both
> directions come with a price. Not an easy choice to make. Can we have
> our cake and eat it too with multiple EPEL repos? One for conflicts
> and one guaranteed to be free of conflicts? With a price we can but
> can we pay that price?
>
> John
> 

<with other messages in this thread considered>


What about something like;

 EPEL MUST NOT conflict with the main RHEL base.
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Client/en/os/ 

 EPEL SHOULD NOT conflict with anything in the RH add-on products, as
considered on a case by case basis.
 
A specific example.  Red Hat Enterprise MRG, http://www.redhat.com/mrg/,
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/RHEMRG/SRPMS .  EPEL should not also offer any of the core packages in that product.  But puppet/facter are in EPEL, and AFAICT were in EPEL before MRG was a product.  puppet/facter are not the core product, but help to configure the core product.  In this case EPEL should work with RH so that both repos can contain puppet/facter.  This could be RH using an Epoch+1, EPEL using a higher cost, RH testing MRG with puppet from EPEL, or some other solution.

So, IMHO, the EPEL policy should be something like "We don't want to
trump RedHat's products"




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