Yum in EPEL [Was: packages that conflict with centos?]
fedora at leemhuis.info
Mon Aug 6 15:10:50 UTC 2007
On 06.08.2007 16:04, Jeff Sheltren wrote:
> On Jul 27, 2007, at 8:48 AM, Michael DeHaan wrote:
>> I haven't looked at these packages yet, but I'm really glad to see
>> this work being done. I mentioned this on #epel a few days ago --
>> lots of folks will be looking for yum to be there.
>> The selfish reason for me to want it is that Cobbler (http://
>> cobbler.et.redhat.com) uses it for repository management and is
>> otherwise broken in EPEL (http://cobbler.et.redhat.com) -- the not
>> so selfish reason is tons of RHEL4 users are already using yum for
>> various things (including maintaining their own repositories of
>> lots of stuff, including, sometimes, updates) and it would be nice
>> if they could get their yum from EPEL and use yum with EPEL if they
> During the EPEL meeting on July 25 -- log here:
> There was some discussion about problems including yum in EPEL.
> The first issue was that these packages don't mess up CentOS users.
> Since these packages all have a lower release than those found in
> CentOS, that should not be a problem since they should never get
> installed in the first place.
> The second issue was that RHEL 4 users can't use yum for system
Or install packages from EPEL that require deps from RHEL4, as long as
they don't set up their own RHEL-repo (see the other mails from dag on
> Do we need to provide a wiki page explaining to RHEL users
> that yum is available only to fill dependencies and shouldn't be used
> directly? What are people's thoughts on this -- especially those
> that use RHEL? Is it confusing to have yum if RHEL can't use it to
> do system updates?
My preferred solution: add a patch that makes yum *on RHEL only* display
a warning like "you should use up2date on RHEL4 to install packages from
EPEL or update RHEL itself" and add a config option to disabled that
warning for those that use mrepo to set up a RHEL-updates repo.
> I'd like to get this discussed here on the list
List is preferred for such discussions, as it's IMHO to time consuming
to discuss all details in a IRC meeting if they havened been discussed
on the list yet -- if they have and no consensus could be found then
it's in my experience easier to come to an agreement in a IRC meeting.
> so that we can make a
> decision about it at the next EPEL meeting if needed.
+1 -- it's still on the schedule.
More information about the epel-devel-list