Packages duplicated between EL-5 sub-channels and EPEL

[Ray Van Dolson]

On Fri, Jan 15, 2010 at 01:29:00PM -0600, Michael Stahnke wrote:
> >
> > The problem with that is that you would need something like:
> >
> > epel-base: packages that don't conflict with any known RH channels
> > epel-not-ds: packages that don't conflict with RH DS channel
> > epel-not-sat: packages that don't conflict with RH Satellite channel
> > ...
> 
> The more I think about it, the more I think the root cause of these
> issues is Red Hat not trying (very hard) to work with EPEL.  The
> steering committee has tried a number of times to get a point person
> involved in RHEL and other products to act as an interface for EPEL
> and had only minimal success.  I have a few questions for RH in
> general, and their view of EPEL.
> 
> 1.  When Red Hat decides to pull a package into RHEL or a layered
> channel, where do they pull the package from? It's been quite obvious
> they don't pull from EPEL source as they have released versions below
> what EPEL has in the repo on several occasions. Was there any effort
> to use the EPEL package, or work with the current maintainer of the
> package in the EPEL/Fedora space?
> 
> 2.  Does Red Hat want EPEL to have the tools system administrators and
> developers commonly need?  I understand RH offering additional
> packages for an additional subscription.  If a company sees value in a
> subscription, they will buy it.  However, if my company had to buy a
> channel for puppet, nagios, createrepo, etc, it would not be cost
> effective to use RHEL at all.
> 
> 3.  Does RH publish what packages they have available in all channels
> anywhere publicly?  That way, EPEL could be slightly more agile in its
> ability to block/update/manage package changes impacted from RH.
> 
> At the RH Summit, RH preaches involvement from the community and
> specifically the Fedora community however, it is a two-way street.
> EPEL can't just react to every change that Red Hat decides to make and
> on RHEL and have it work perfectly each time.  EPEL tries hard to be
> the best package repository it can be, because we believe in the RHEL
> family of products, however we are only on the receiving end.
> 
> I realize I haven't offered a whole lot of solutions here, but if we
> had more information it may be easier to come to agreement on one.
> 
> stahnma

Assuming we can realistically expect answers to the above from RH in a
reasonable amount of time, I'd say getting these points addressed would
be a blocker on this entire problem.  No sense in beginning to
implement technical solutions for a moving target...

Ray