Once upon a time, Jan-Frode Myklebust <[email protected]> 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 <[email protected]> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
