On Tue, Jan 12, 2010 at 9:48 AM, Michael Stahnke <[email protected]> wrote: >>>> Do we stick to our policy as is or do we want to make a revision? > I propose a revision. I propose we don't step on anything in the AP > channels. Also, if we are having a collision problem with other Red > Hat provided layered channels, a bug could be filed and we could > attempt to resolve it by a lower package number or something. It's > not that I blatantly want to ignore other channels, it's that if we > exclude all of those products in EPEL, EPEL becomes less useful to the > enterprise customers it was aimed at. > >>> It seems to me looking in from the outside that you have already made >>> a revision to the policy by including 389, nagios, and possibly other >>> things. Might as well move on the figuring out what the real policy is >>> going to be and correctly documenting it. > > 389 isn't a policy violation, Red Hat does not ship it. They ship Red > Hat DS, which is based from 389 but not the same thing. I would > assume we could ship spacewalk, freeipa and others in a similar > fashion.
If it doesn't conflict with an installed RHDS it isn't a problem. I see it as something of a problem if it does regardless of the policy. I assume that all the 389 packages probably have different names so it is likely safe but I don't know what else it might pull into the repo if anything. And given the fact that Red Hat is now naming packages delivered with Satellite as spacewalk-* I'm not very confident that the wall between what is upstream and what Red Hat provides is secure enough to avoid conflicts in any of these products. My understanding of EPEL's mission was that it would allow me to begin with a RHEL + layered product box, configure EPEL, get additional stuff without creating new problems. I think that is a wonderful mission. If this becomes I can begin with a box with anything I can get from AP, configure EPEL, get additional stuff without creating new problems I think we have a slightly less wonderful mission abstractly but perhaps a more effective mission in the real world. John _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
