Packages duplicated between EL-5 sub-channels and EPEL

Rich Megginson rmeggins at redhat.com
Fri Jan 15 16:21:05 UTC 2010


inode0 wrote:
> On Thu, Jan 14, 2010 at 9:55 PM, Ray Van Dolson <rayvd at bludgeon.org> wrote:
>   
>> On Thu, Jan 14, 2010 at 09:44:01PM -0600, inode0 wrote:
>>     
>>> On Thu, Jan 14, 2010 at 9:40 PM, Michael Stahnke <mastahnke at gmail.com> wrote:
>>>       
>>>> <snip>
>>>> If EPEL would pull all of those packages it would become basically
>>>> useless to me.
>>>>         
>>> I don't really see how pulling all those packages can be the direction
>>> we go. Way too disruptive to EPEL users at this point.
>>>
>>>       
>> Guess they could be moved to an "epel-unpure" repository. :)
>>
>> (In favor of the status quo personally not having read all the
>> discussion yet...)
>>     
>
> Having given this some more thought here is what I think we should try to do.
>
> (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"?
> 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.
> John
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list
>   




More information about the epel-devel-list mailing list