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

[Ton Voon]

On 27 Apr 2007, at 11:06, Gavin Carr wrote:

> I really see two separate issues here:
>
> a. Do we bundle Nagios::Plugin (and dependent modules) with the
>    standard tarball, and support its installation from there, or
>    do we just do external installation via CPAN or an OS package?

We bundle the tar gz files for N::P and dependent modules with the  
distribution in, say, perl-mods/.

I've been looking at Krang, which bundles the perl tarballs with  
their code (http://www.krangcms.com/docs/building_perl_modules.html).  
As an aside, they check the individual licences permits them to re- 
distribute - we should check that too.

People that want CPAN or OS packages are free to install themselves.  
In which case, the configure script would disable the local install  
if N::P is found in system dir with sufficient version.

> b. Do we install Nagios::Plugin to the standard perl library
>    directories, or do we allow and support installation elsewhere
>    (e.g. to a local nagios tree)?

We always install into a nagios tree, say, /usr/local/nagios/lib. We  
don't support installation into system dirs - use CPAN or do it  
manually if you want that (okay, that's probably a bit harsh - I  
guess we could provide a configure flag, but it is not a priority).

If a user decides to install from CPAN or OS packages, obviously that  
would be placed in system directories.

> It sounds like there's a reasonable consensus on (a) that we do
> want to bundle N::P. This needs something like your nanocpan, and
> presumably a reasonably test suite for the perl plugins to ensure
> that the set of modules we're snapshotting do play nicely together.

I'm thinking that the nanocpan is going to be based on Krang's  
techniques. I'd like to make nanocpan generalised so that it can be  
used outside of Nagios Plugins and can be given back to the perl  
community.

I don't think any additional test suites are required, right? As long  
as N::P's test suite pass, then the dependent stuff has done its job.

The beauty about the snapshoting is that we know for this specific  
combination of perl modules, N::P will work (because we'd also be  
running tinderbox builds daily to prove it too).

> I'm not sure a good case has been made for (b) yet - to play devil's
> advocate, why don't we just mandate that N::P and friends, if
> installed directly, always get installed to the standard perl lib
> tree? This makes the whole search problem go away. Is there a good
> case for doing anything else?

I haven't found the search path to be a problem. I guess lower  
versions of perl may pose a problem - I don't have a handle on this  
yet. There may need to be some extra work done there to support those  
lower levels.

Installing into system directories affects other people's code. I'd  
rather not be responsible :)

Yes, there's potentially duplication of perl modules. But packagers  
can tune things so that nagios plugins are installed without the perl  
modules and they set dependencies for N::P externally.

Ton

http://www.altinity.com
T: +44 (0)870 787 9243
F: +44 (0)845 280 1725
Skype: tonvoon