This may be considered a dupe of bug #498292 and I'll not object if that is its disposition (I'll just return there to make the argument that follows). More than a year ago, nagios-plugins.org was hijacked (for want of a better word) by Nagios Enterprises, the domain's owner. The domain was redirected to a web host under their control, containing a copy-and-paste recreation of the original site. The incumbent dev team were replaced wholesale by untested newcomers (as far as anyone can establish), and the project goal changed from supporting the many Nagios-compatible monitoring engines, to only supporting Nagios itself. Gentoo devs were aware of this (see bug #498292) but the decision was taken to ignore the issue, and users were left in the dark. Releases made under the new team could at the very least have included an einfo explaining the change, but did not. Subsequent gentoo releases of nagios-plugins dropped the contrib plugins from the ebuild, which broke my system without warning. This was a big functional change that indisputably merited an alert when upgrading. Leaving aside the "politics" (as it was drily dismissed in the other bug), due to the change in project goals, people currently using this package with other monitors are likely at some point to find their systems similarly broken, and it will be "by design" in their case. Perhaps this has already happened, though I haven't seen any bug that suggests so. In order to head off any such issues, and to ensure awareness of the changes, I propose that >=nagios-plugins-2.0.3 be masked and recreated as nagios-core-plugins (or similar), with advice given on the changes of dev team and project goals (and maybe a mention of the lost contrib plugins), and offering both nagios-core-plugins and net-analyzer/monitoring-plugins (added yesterday, see bug #520196) as upgrade paths. This is not a political issue, it's a usability and user-transparency issue. I hope my own experience illustrates that.
(In reply to Robin Bankhead from comment #0) > Subsequent gentoo releases of nagios-plugins dropped the contrib plugins > from the ebuild, which broke my system without warning. This was a big > functional change that indisputably merited an alert when upgrading. Contrib was dropped by upstream. https://github.com/monitoring-plugins/monitoring-plugins/blob/master/NEWS 1.5 2nd October 2013 The contrib directory has been removed from this distribution https://www.monitoring-plugins.org/news/release-1-5.html The contrib directory has been removed. These days, sites such as Nagios Exchange and Monitoring Exchange serve as much better places for publishing plugins not maintained by the Nagios Plugins Development Team.
Thanks for the info, but what does that change? Gentoo failed to notify users of the change, which in my opinion they should have. Just because it was old news by the time we actually got a package that reflected it, changes nothing of what I've said above.
Sorry, more accurately it (arguably) decouples that personal issue from the larger issue I raised. It doesn't invalidate the latter in any way.
If you ignore the history, "nagios-plugins" vs. "monitoring-plugins" does a pretty good job of indicating the upstream source and their priorities. The nagios-plugins come from Nagios targeting Nagios, while the monitoring-plugins don't. When specifying the *-plugins dependency, the other frameworks can put monitoring-plugins first in the list. That will cause it to be preferred by portage and chosen by default. (I have yet to ping the maintainers of Icinga et al., but I will in a minute). As far as the contrib plugins go, this *was* a major version upgrade, from 1.x to 2.x (in an unstable ebuild!). We can't rename the project every time a backwards-incompatible change is made. Anyone not prepared to deal with a major version upgrade can specify the 1.x version when they install the package. (I did also send an email to gentoo-user before I committed the 2.x ebuild, asking for testers.)
It is a little hard to *entirely* ignore the history (and I'd be lying if I said I wasn't influenced by it, although I'm trying to be objective over how it was/is dealt with here). If a rename isn't required to achieve what I believe is appropriate handling of the matter, then I'm fine with that. This is where my limited knowledge of Portage (after a decade, disgraceful I know) shows through I suppose. I didn't consider the dependency-precedence approach you mention that the other monitors' ebuilds can take; that certainly works for them. However that alone doesn't achieve the stated goal for one group: For my part, I'm not particularly interested in replacing nagios-core with one of the rivals unless/until I'm sure it's a technically beneficial move. OTOH, I'm planning to move to monitoring-plugins because I see it as the real continuation of the package I knew as nagios-plugins. Thus, whatever may happen with the other monitors, I have not been and won't be given any indication that the package I'm using has been re-homed, re-staffed and sent off in a new direction -- to all intents and purposes, it's no longer the same package. To disagree with that assessment is to infer that the old nagios-plugins wasn't generally known to support all those other monitors as well, which IMHO it was, but perhaps this is where I'm wrong(?) As to whether doing due diligence on a major-release would have revealed either the dropping of contrib or the, er, "political" issue: I guess I have to say "yes" to the former (although a few words in einfo isn't unreasonable to expect IMHO, plenty of ebuilds make more noise about smaller changes). To the latter: a lot less likely. After all, the website appeared unchanged unless one was looking for the changes, and about the only mainstream reportage I can find about it is a Slashdot story which, of course, was nearly a year old by the time 2.0.3 hit the mirrors. If renaming isn't going to fly, what other options are there for making the affected users aware of the choice? The next ebuild could mention it in einfo, and I think I'm right in saying that the existing 2.x ebuilds could also be altered to add it, but the only way to advise currently up-to-date users would be a revbump purely for the sake of doing so (or an item in eselect news). Is that all correct? If so, the only question is whether you deem the issue important enough to take that action to be sure affected users are aware, or feel you'd only be doing it to placate one uppity user ;) As the matter seems so little talked-about globally, it feels a bit like the latter even to me, but you must ask: are people not talking about it because they don't care; or because they don't know?
I think the time to act (if we were going to do anything) has passed. Nothing too bad has happened with nagios-plugins, and monitoring-plugins are still trudging along faster than their "official" counterpart. Some day I will probably mask nagios-plugins and tell everyone to use monitoring-plugins instead: it's silly to have two copies of the same programs. But for now it's less work to bump nagios-plugins occasionally and keep them in the tree.
