Comment 82 for bug 1273484

(In reply to Scott Wilkerson from comment #77)
> (In reply to Sam Kottler from comment #75)
> > (In reply to Mark Hill from comment #74)
> > > (In reply to Sam Kottler from comment #69)
> > > > (In reply to Mark Hill from comment #65)
> > > > > This must be some kind of joke right? Are there serious considerations to
> > > > > get rid of the nagios-plugins RPM? I thought it was a bad idea before, but
> > > > > now after reading that last comment and associated blog article, I am
> > > > > outraged! And are we really worried that the new team writing the code for
> > > > > these plugins are not going to be up to par? REALLY? I'm pretty sure a
> > > > > fifth-grader could meet the standards the previous team set, It isn't
> > > > > excately a high bar to meet. I promise I am not tyring to be degrading, and
> > > >
> > > > "I'm pretty sure a fifth-grader could meet the standards the previous team
> > > > set" but you're not trying to be degrading...
> > > >
> > >
> > > Fair enough, that was a bit harsh, I let my emotions get the better of me
> > > and I apologize.
> > >
> > > > Anyways, given I don't find your name in any of the SCM logs, email lists,
> > > > or anything Nagios related (other than promoting Nagios XI on stack
> > > > overflow) I'm not sure I trust your opinion on this.
> > > >
> > >
> > > The sensitive nature of my work requires that I keep a low profile. (I even
> > > had to receive clearance to post here) So although you don't see my name
> > > publicly, several others who have commented here are familiar with my
> > > extensive nagios work.
> > >
> > > > > I sincerely appreciate the work they did! I just think it is ridiculous to
> > > > > assume that because of the changes that got everyone all upset we should
> > > > > drop the nagios-plugins rpm and move to nagios-insertyourideahere-plugins.
> > > > > As other "community members" have already said, I do not want to deal with
> > > > > all of the dependency issues this creates, just because of a little pissing
> > > > > match.
> > > >
> > > > It actually creates virtually no dependency issues AFAIK; can you elaborate?
> > > >
> > >
> > > We have a massive nagios infrastructure built (and team dedicated to it). We
> > > rely heavily on the nagios-plugins rpm. We have scripts all over the place
> > > that use yum to install and update the plugins. And now by the sounds of it,
> > > we are going to have to touch each one of these if we want the
> > > nagios-plugins from the new team? Does that help clarify my concern?
> >
> > It does, thanks. That being said it's just updating a bunch of package
> > names; there won't be any additional process. No paths will change if you
> > stick with the nagios-core-plugins package.
> >
> > >
> > > > >
> > > > > Sam: I really appreciate you dealing with this, but please, keep a straight
> > > > > head on this.
> > >
> > > Again, I really appreciate your work on this Sam. I don't have a stake in
> > > this other than the time my team is going to have to spend fixing stuff if
> > > you decide to force us to go to 'nagios-core-plugins'. And my biggest
> > > concern is what if my team misses one? We are going to have mismatches
> > > across our various networks, and anything we have built on top of that will
> > > break. And yes, this would be easy to accomplish if are networks were not
> > > completely isolated from one another. Several of our network require
> > > out-of-band management, so again, I think you understand my concern. This
> > > just seems like a very unnecessary headache in the making.
> >
> > Understood and I totally sympathize with you on that, but this wasn't really
> > my decision. You can talk with Nagios Enterprises about how they're making
> > the lives of their users more difficult - maybe they'll listen.
>
> @Sam - How is it that you think Nagios Enterprises is making the lives of
> their users more difficult?
>
> Nagios Enterprises wants the nagios-plugins package to continue to exist
> with the project that they own/maintain.
>
> Nagios Enterprises wants the millions of installs of Nagios and it plugins
> to continue to use the same package names as always for the projects which
> they own, no matter who they appoint to the team.

You should read DJ's remarks from above.

>
> Changing of the package name to not refer to the official Nagios Plugins,
> with the team the project owner put in place is what would be making the
> lives of the users more difficult.
>
> A worst case scenario would be to have an install/upgrade of nagios-plugins
> automatically upgrade to a package created by the Monitoring Plugins team.

Yes, this would be a worse case scenario for your employer. It'd be the right thing for the community in my opinion.

>
> This would be akin to running Fedora on your machine and after running yum
> update, you find you have Linux Mint installed and no longer Fedora...
>
> Would this be what you expected?