nagios shipped by RedHat, but in a specific subscription channel

inode0 inode0 at gmail.com
Wed Jan 13 23:54:35 UTC 2010


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.

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




More information about the epel-devel-list mailing list