Thoughts from last meeting

[Bryan J Smith]

Chris Adams <cmadams at 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