Hello...
On Wed, 2010-01-13 at 17:54 -0600, inode0 wrote: > 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. > 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" [email protected] 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. _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
