[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Packages duplicated between EL-5 sub-channels and EPEL

inode0 wrote:
On Thu, Jan 14, 2010 at 9:55 PM, Ray Van Dolson <rayvd 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 gmail com> wrote:
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
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.

epel-devel-list mailing list
epel-devel-list redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]