[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: nagios shipped by RedHat, but in a specific subscription channel


On Wed, 2010-01-13 at 17:54 -0600, inode0 wrote:
> On Wed, Jan 13, 2010 at 5:28 PM, Christopher <chrismcc 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.


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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]