Could we add this to the next steering committee meeting? Here are the issues:
1. "Layered" products, such as cluster server, ship some support packages like perl modules, etc. Should those be allowed in EPEL? They are not part of core RHEL. IMHO, as much software as possible should be available for everybody. At my place of employment, if I need a package and it's not in EPEL, I then have to build/maintain my own, which is what EPEL hopes to stop. I could see the EPEL committee denying some 'core' packages of each layered channel, (such as RHDS core packages, cluster server core packages for RHEL 4, etc). 2. Even competing with layered products seems bad. If we would like RHX to have the same packages as in EPEL but be able to buy support for them, shouldn't RH do the same? That way the software is available to those who would like to preview it, use it with CentOS, Scientific, etc. I realize this contradictory to what EPEL started with, but our goal should be software to everybody, at least that's what I think. 3. What about products such as Free IPA vs IPA, Fedora DS vs RHDS, Spacewalk vs Satellite etc? If there is a fully open offering, can we put it in EPEL and not officially be 'conflicting' with the RH channel for it? 4. Firmware packages that are on the supplemental EL discs. To me, this is just to make some hardware work, shouldn't that be easily available? As an enterprise customer, it'd be a lot easier to have it in EPEL (which I am going to use anyway) than to have to download/import the supplemental disc. I am sure there are more questions and conflicts, and I don't want to stomp on Red Hat, but I would like to make EPEL as usable and complete as possible. PS I won't be the EPEL meeting Monday. stahnma _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
