Packages duplicated between EL-5 sub-channels and EPEL

[Ray Van Dolson]

On Fri, Jan 15, 2010 at 09:21:05AM -0700, Rich Megginson wrote:
> >(1) Allow things that come from layered products to be replaced (here
> >I am defining layered products as being those from channels not
> >associated with AP).
> I can think of a specific case that will break something.
> 
> Let's say for example that I am a RHEL customer, and I'm running Red
> Hat Directory Server.  The packages idm-console-framework-N and
> adminutil-N come from that channel.
> 
> Now let's say I set up EPEL on this box for something unrelated to
> directory server (e.g. I need to use git).  Since 389 is also in
> EPEL, there are packages idm-console-framework-M and adminutil-M in
> EPEL, where version N < M and version N is not compatible with M.
> If I then do a yum update, yum is going to update
> idm-console-framework and adminutil to the M versions, breaking my
> directory server.  This is unacceptable.
>
> >(2) Try to keep a current list of conflicts so they can be easily
> >excluded from the EPEL repo by the user in advance (i.e., at EPEL
> >configuration time) and announce new conflicts somewhere so the
> >exclude list can be kept up to do more or less to minimize conflicts
> >for those who just don't want them. Having such a current list
> >commented out in the epel-release might work really well for the
> >user?!
>
> So in my case above, how could we provide an exclusion list that
> says "pull idm-console-framework and adminutil only from the RH
> channel unless the system is not subscribed to the RH channel"?
>

Maybe we need an EPEL yum plugin with some smarts to help figure out
this sorta stuff. :)

(That leaves up2date out on a limb I guess though)

The exclude= seems a little hacky and bound to cause problems.

> >That is a little extra work to help those who want only the "pure"
> >version of the repo by enabling them to do something to create it and
> >would let people who don't care about it just go on about their
> >business as usual.
> I think EPEL is extremely useful to have, even if packages like
> spacewalk, directory server, and cert system are not in it.  As a
> user of EPEL, I find it very useful.
> 
> As a 389 developer who wants a wider audience, though, I really like
> being able to use EPEL as a distribution channel for 389 (having had
> a private yum repo for this for years as the alternative :P.  The
> only other alternative to this is centos-ds, which is not suitable
> for the purpose of 389 development, which is to get the 389 bits
> into the hands of as many people as possible, and release early and
> often.
> 
> Perhaps we should have a "base" EPEL channel and "layered" channels
> on top?  That way, I could use the base EPEL channel for things like
> git, etc.  If I then wanted to use spacewalk or 389, I could add the
> epel-spacewalk.repo or epel-389.repo to my yum config and get those
> channels.  By doing so, I would know explicitly that I am doing
> something that would break the corresponding RH package, rather than
> getting a nasty surprise.

In the end, this might be the simplest.  The sysadmin will just have to
know what they're doing and actively choose to include the "layered"
channels and exclude the necessary packages.

Ray