Overlapping packages: Getting closer to a policy

[Toshio Kuratomi]

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>

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.

* Why not prohibit overlaps with all channels?

Primary reason is that channels conflict with each other so we can't enable
all of them in the buildsystem successfully.  This also seems to run counter
to our other desired criteria.

* What now?

We need to work on the criteria and decide what ones we're actually going to
go with.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20120608/5f708779/attachment.sig>