On Fri, Jun 08, 2012 at 02:14:40PM -0400, inode0 wrote: > On Fri, Jun 8, 2012 at 1:35 PM, Toshio Kuratomi <a.bad...@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
pgpSkVcOE7qdn.pgp
Description: PGP signature
_______________________________________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
