inode0 wrote:
On Thu, Jan 14, 2010 at 9:55 PM, Ray Van Dolson
<rayvd(a)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(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list