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