Chris Adams <cmadams(a)hiwaay.net> wrote:
The problem with that is you'd need an ever-increasing
combination of
additional EPEL repos. There'd be an "EPEL base" that doesn't
conflict
with any layered products (but has almost no packages),
but then you'd need a bunch of combinations of "doesn't conflict with foo
and bar but may conflict with baz".
If there are RH layered products that can conflict with each other (as I
believe somebody said there may be), it becomes an even more impossible
problem to solve.
If there are conflicts in versions, as well as trailing v. leading,
this will be an issue in EPEL regardless of exclusion/inclusion. You
could even build an unified "Fedora Enterprise Linux" repo with
everything and it would still happen.
IIRC somebody suggested yum-priorities. I think that that is the
only
sane way to go; make epel-release require yum-priorities and set EPEL (a
single repo) to a lower priority than then RHN channels. Let EPEL
maintainers decide what they want to maintain and "let the buyer beware"
if somebody fiddles with EPEL priorities. There are just too many
potential combinations of conflicts to try to handle any other way.
Unfortunately that does not solve the issue for RHN Satellite Server,
or even Spacewalk for that matter. Clone and custom channels become
issues, anything where the packages are not located under the NULL
(upstream) directories.
That way, if RH directory server folks want to maintain a set of
packages in EPEL as well, they can do so, and explain to their customers
how to use them (which would basically be "unsubscribe your test systems
from the directory server layered product RHN channel").
Which leads to several suggestions to segment into two (2), so
everyone realizes where something does and does not conflict. That
solves most of the issues for all parties and users.
--
Bryan J Smith - Professional, Technical Annoyance
http://www.linkedin.com/in/bjsmith