On Fri, Jun 8, 2012 at 10:35 AM, Toshio Kuratomi <a.badger(a)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