Overlapping packages: Getting closer to a policy
Toshio Kuratomi
a.badger at gmail.com
Fri Jun 8 17:43:01 UTC 2012
On Fri, Jun 8, 2012 at 10:35 AM, Toshio Kuratomi <a.badger at 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
More information about the epel-devel-list
mailing list