Thoughts from last meeting

[Chris Adams]

Once upon a time, Jan-Frode Myklebust <janfrode at tanso.net> said:
> I completely agree. Secondary repo which would be disabled by default
> holding packages that could conflict with RH-channels would be ideal for
> our usage. It would also open up for actively including stuff that's in
> RHEL layered products -- for unsupported usage. 

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.

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.

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").

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.