Overlapping packages: Getting closer to a policy

[Toshio Kuratomi]

On Fri, Jun 08, 2012 at 02:14:40PM -0400, inode0 wrote:
> 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?
> 
Yes.  I'll reply more below.

> >
> > * 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. 

Alright.  We're operating under mis-assumptions then.  In the meeting it
seemed like this list was all the things that you could get with a basic
subscription:

http://fpaste.org/xAPF/

But that could be wrong or I could have interpreted what the list was
supposed to mean incorrectly.

> 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.
> 
Correct.  And I agree that that seems dangerous if not everyone has access
to them now.  Can we figure this out?

-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/e7899438/attachment.sig>