[Nagiosplug-devel] Integrating Nagios::Plugin into the distribution
Ton Voon
ton.voon at altinity.com
Fri Apr 27 14:05:51 CEST 2007
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
More information about the Devel
mailing list