nagios shipped by RedHat, but in a specific subscription channel

Stephen John Smoogen smooge at gmail.com
Tue Jan 12 17:00:50 UTC 2010


On Tue, Jan 12, 2010 at 9:09 AM, inode0 <inode0 at gmail.com> wrote:
> 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.

Ok this is the problem with strict policies versus writing to intention:

If Red Hat were to mirror everything in EPEL as a channel called
"Unsupported Community Packages from EPEL" our logical conclusion
would be to remove all those packages from EPEL... which would remove
them from that channel, which means we could add packages back to EPEL
which would...

So what is the intention that we are wanting? And can we write to
that. Here is a list of things that come to mind in no meant order.

1) We do not wish to replace or conflict with the channels from a Base
install. [EG if its on the DVD RHEL provides we don't replace or
conflict.]
2) We do not know what is in all the other RHN channels. We do not
know what will be in an update either.
3) Red Hat people would like that their 'free' versions of packages
were in EPEL (the spacewalk people would like spacewalk, the 389
people would like 389, etc) as it allows them to push newer packages
to people who are testing them in real environments.
4) However inclusion of this will cause problems with other RH products.

So how should we word it to best work out intention, should we look at
our own layering of stuff, or something else... and whatever we decide
lets do it.. this seems like the 8th time this discussion has come up.


-- 
Stephen J Smoogen.

Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning




More information about the epel-devel-list mailing list