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

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

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?


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