Overlapping packages: Getting closer to a policy

[Stephen Gallagher]

On Fri, 2012-06-08 at 11:39 -0700, Toshio Kuratomi wrote:
> 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?

For packages that overlap outside of base+optional, could we just agree
to allow SRPM rebuilds with the exception that the EPEL release numbers
must always be less than the official RHEL release numbers?

i.e. if we have mypackage-1.0-8.el6 in the HA channel, we can opt to
repackage it in EPEL if-and-only-if the release number is 7.9 or lower
(making it mypackage-1.0-7.9.el6).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20120608/0420bb5c/attachment.sig>