[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Packages duplicated between EL-5 sub-channels and EPEL

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]