Comment 34 for bug 1273484

Revision history for this message
In , Michael (michael-redhat-bugs) wrote :

Yeah, that's good news!

I've looked into the list of dependencies below in order to also sort upgrade path issues.

(In reply to Sam Kottler from comment #24)
> I agree that it's too early to decide on the issue. These are the packages
> in EPEL that depend on nagios-plugins and what do we want to do about them?
> Create community-plugins-* alternatives?
>
> [...]

* nagios-plugins-*-1.4.16
is built from nagios-plugins.spec so that's gotta be a 1:1 copy (or a local requires in the main spec file)

* nagios-plugins-nrpe
is built from upstream nrpe, and not part of the monitoring plugins project. it contains 'check_nrpe' but that only works with the remote clients actually run the nrpe daemon. Apart from that the current NRPE implementation lacks off good security layers, so it shouldn't be touch anyway.

* nagios-plugins-rhev
seems to be deprecated: http://pkgs.fedoraproject.org/cgit/nagios-plugins-rhev.git/log/

* nagios-plugins-lcgdm
seems to be a cern specific package, not sure if anyone uses it.

* nagios-plugins-bdii
doesn't depend on nagios-plugins, but nagios-common.

And then there are some additional plugins which require the nagios-plugins rpm for providing the directories (http://pkgs.fedoraproject.org/cgit/nagios-plugins-openmanage.git/tree/nagios-plugins-openmanage.spec#n29)

* nagios-plugins-openmanage
* nagios-plugins-check_sip
* nagios-plugins-check-updates

That could possibly be overcome by providing a generic monitoring-plugins-common package providing users/paths/etc if those packages are reworked as well. check-updates is the most common plugin, so it should be made available under the new package name space as well imho.

(In reply to Drew Blessing from comment #31)
> Sam,
>
> By having monitoring-plugins in EPEL 6 what options does that leave for
> nagios-plugins? Continue with the new nagios-plugins team as provider for
> the packages, remove them, or make them a pointer toward the
> monitoring-plugins? I'm just looking for clarification. It seems like maybe
> the entire path forward should be decided before making any changes,
> including the addition of monitoring-plugins.

I would remove the new team by Nagios Enterprises from any further decisions made in this bug. I've opened this ticket in the means of updating the current package. If they require their newly formed sources in Fedora, they should ask for a package review, but in a different task / bug.

Our scope here is to solve the existing problem with changed sources, and once Sam gets the monitoring-plugins package into review, it's reasonable to make nagios-plugins package a transitional package. But I also understand the need for a clean upgrade path, in either now EPEL6, and future EPEL7/el7.

Beyond that, I'd suggest to "freeze" the nagios-plugins package and don't release any updates, until a proper solution is found.