[Nagiosplug-devel] Integrating Nagios::Plugin into the distribution

[Gavin Carr]

On Sat, Apr 28, 2007 at 11:58:47AM -0400, Thomas Guyot-Sionnest wrote:
> On 28/04/07 08:25 AM, Gavin Carr wrote:
> > On Fri, Apr 27, 2007 at 01:05:51PM +0100, Ton Voon wrote:
> >> Installing into system directories affects other people's code. I'd  
> >> rather not be responsible :)
> > 
> > Okay, so you're seeing the whole separate-install thing as a feature,
> > isolating you from screwing up (or being screwed up) someone else's
> > libraries?
> > 
> > I guess I'm seeing that risk as relatively small, especially given the
> > modest set of dependencies we have. I'm much more suspicious of the 
> > duplication problem. If you end up having multiple versions of the same
> > modules in different locations, you're going to be prone to all kinds
> > of weird problems if you're not careful. Simple example: imagine an 
> > N::P from CPAN and a different N::P installed in /usr/local/nagios, and 
> > home-grown or third-party perl plugins behaving in very confusing 
> > ways dependent on which way the lib path is set up ...
> 
> Have you read my arguments on this? I believe that changes in the CPAN
> libs should not affect Nagios-plugins and vice-versa. The two problems I
> see are:
> 
> 1. Bugs/incompatibilities that could slip in newer version of
> Nagios-plugins. Since we'll be allowing newer version of N::P to be
> installed we could get bug reports that only affect certain combinations
> of packages.

Sure. But it's just an extra version number to check.

> 2. Upgrading N::P on systems that have a too old version could possibly
> break existing plugins that are not part of Nagios-plugins. Some of
> these plugins may come from sources like Nagiosexchange and their
> developers might not be offering a fixed version (and not all systems
> admin write Perl)

Again sure, but I think this risk is pretty small. You need a non-
backwards-compatible change (I don't believe we've had any so far), 
and one or more plugins that depend on that behaviour and aren't 
trivially correctable.

> I don't think there's good chances of having "weird problems" if N::P is
> in a separate dir. Nagios-plugins Perl plugins will all have the "use
> lib" instruction to get the packaged N::P, while all other should use
> the system one (unless the developer intended to use the local one).  In
> either case it shouldn't be broken though.

I just think duplication is a bit like denormalising a database
schema - it's generally bad practice, but sometimes the benefits
make it worthwhile. You and Ton clearly see the benefits there;
I think I'm just cautious about the potential costs too.

Cheers,
Gavin