Overlapping packages: Getting closer to a policy

[inode0]

On Fri, Jun 8, 2012 at 1:35 PM, Toshio Kuratomi <a.badger at gmail.com> wrote:
> At today's EPEL meeting we got a bit closer to a new policy.  Had a few
> proposals and started tweaking both the wording and the criteria that have
> been presented.
>
> 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>

I'm a little confused on the lb and ha points here and in the FAQ. So
here we are saying that EPEL6 won't include packages from those
Add-Ons?

> 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
>
> In coming up with these criteria, we were attempting to satisfy these
> identified needs and desirable qualities:
>
> * Must be usable in the buildsystem
> * Would like to make it easy on contributors to build and run the packages
>  they are creating.
> * Set expectations appropriately for users of EPEL for what they can rely on
>  as being protected and what is not
> * Limit the conflicts that can occur with Red Hat channels in some manner
> * Limit confusion for users of EPEL as much as possible given the other
>  constraints.
>
> FAQs:
>
> * Why not just stick with os or os and optional?
>
> It seemed like the things in lb and ha were generally useful to a large
> number of people, are currently enabled in the buildsystem, and are
> available to everyone who has a RHEL basic subscription currently.  Removing
> them would mean trying to get them packaged for EPEL and also that we'd
> conflict with more packages that RHEL users could be using currently.

Really confused by this. LB and HA are useful but they are not
available to everyone who has a basic RHEL subscription currently.
They are both Add-Ons requiring additional subscriptions for access to
them. What does it mean that they are currently enabled in the
buildsystem? If that means other packages built for EPEL can include
dependencies on what is in these channels that seems very dangerous
unless they are packaged in EPEL since not everyone has access to them
now.

John