> > 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 _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
