technical solution/workaround for EPEL vs. RH sub channel

Christopher chrismcc at pricegrabber.com
Mon Jan 18 19:59:50 UTC 2010


Hello...

  What about the following idea as a solution to RH vs. EPEL conflicting
packages?  Extend yum either in the core code or as a plugin to allow
exclude=@group.  Then the EPEL repo could contain groups
@rh-sub-channel-foo, etc. with EPEL packages that conflict.  That would
allow the sysadmin to selectively exclude packages for RH sub projects
they get via RHN.  Even if there are technical problems with RHEL4 or
RHEL5, this approach could still work with RHEL6.  

yes? no? maybe?


The epel.repo file could contain something like:

# repo file for epel
# If you wish to avoid conflicting with a RedHat channel you subscribe
# to, you can use exclude="@rh-group-foo".
# get get the list of groups group run
# yum grouplist --disablerepo='*' --enablerepo=epel 
# or see http://some.url/EPEL
#
# warning subscribing to RH sub channels and EPEL without checking for
# package conflicts may kill kittens.

[epel]
name=Extra Packages for Enterprise Linux 5 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/5/$basearch
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-5&arch=
$basearch
failovermethod=priority
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL

# exclude="@rh-group foo"


-- 
Christopher McCrory
 "The guy that keeps the servers running"
 
chrismcc at pricegrabber.com
 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.





More information about the epel-devel-list mailing list