On Fri, Jun 8, 2012 at 10:35 AM, Toshio Kuratomi a.badger@gmail.com wrote:
The basic framework that our proposals seemed to have was:
EPEL6 will not conflict with os, optional and specific other RHEL channels. Currently those are lb and ha. Other channels may be added [based on this criteria]. Overlaps are allowed to resolve packages missing on specific arches according to <link>
The sticking point is what to put in for the criteria. Â Suggestions given at the meeting were a combination of the following:
- case by case basis
- Does not conflict with os, optional, or other channels already enabled
- Available to people who have a basic subscription
For me, I feel the no conflicts portion is a blocker as that's what allows us to use the packages in the buildsystem. I really like the basic subscription criteria because it seems to be a good cutoff point for what a contributor to EPEL can be reasonably expected to have access to in order to build packages and run the results but it's not a blocker like the first one. So the proposal I came up with at the meeting was roughly:
EPEL6 will not conflict with os, optional and specific other RHEL channels. Currently those are lb and ha. Other channels may be added if they're available to people who have a base subscription to RHEL and the new channels don't conflict with the packages from Red Hat that we are already promising not to overlap with. Overlaps are allowed to resolve packages missing on specific arches according to <link>.
Wording can be tweaked as we see fit.
-Toshio