nagios shipped by RedHat, but in a specific subscription channel

inode0 inode0 at gmail.com
Tue Jan 12 16:09:09 UTC 2010


On Tue, Jan 12, 2010 at 9:48 AM, Michael Stahnke <mastahnke at gmail.com> 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




More information about the epel-devel-list mailing list