On Wed, Jan 13, 2010 at 5:28 PM, Christopher <[email protected]> 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 _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
