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

[Matthias Eble]

Hi all,

> If N::P is installed in the perl system libraries, no paths need 
> changing. If N::P is installed elsewhere, the perl plugins need to know 
> where to find N::P.

I think Ton's proposal using FindBin is the only way to meet this need.
I like it.

> I think it comes down to two choices:
> 
> 1. Expect N::P to be installed from an external mechanism, either 
> manually installed via CPAN, or using a OS specific package. We'd have 
> to make sure the Nagios Plugins requires these packages (amend various 
> spec files, update REQUIREMENTS file, etc)
> 
> 2. Install N::P (and other dependent perl modules) in a (./configure 
> chosen) location.
> 
> (1) is easier, though it pushes responsibility onto packagers. As N::P 
> and the perl scripts in Nagios Plugins are updated, there is a 
> dependency on packagers to make the newer version available for us to 
> require on.
> 
> (2) is harder, though we would have control over what versions are 
> recommended.
> 
> Ideally we need to support both, so that packagers can include only the 
> minimum software required for Nagios Plugins, but a "direct install" 
> case will still work for most users.
>

To me there is one reason to install N::P locally: CPAN setup. I don't 
want to download N::P+dependant modules to every host using cpan. We 
distribute the the plugins with rsync into a seperate directory 
(/opt/nagiosplug)
Syncing stuff to /usr/lib/perl5 is not clean enough to me since it could 
overwrite a locally installed module, and as ton already said.


> My proposal is this:
> 
> ./configure has two new options: --enable-local-perl-modules, 
> --disable-local-perl-modules. The default is to search for N::P and 
> enable if not found or disable if found.
> 
> --disable-local-perl-modules does nothing beyond current
> 
> --enable-local-perl-modules will install N::P from a new top level 
> subdirectory I'm calling "nanocpan". In this directory is the tar file 
> from CPAN for N::P plus all the dependent perl modules. At make time, a 
> "perl Makefile.PL PREFIX=$prefix" (and some other options that I'm not 
> too sure of right now) and "make" will be run to compile all the 
> required perl modules - this will be recursive, so other dependent perl 
> modules will be included. At make install time, those perl modules will 
> be installed into, say, $prefix/lib.
I'd prefer to call the flag "bundled-perl-modules" for clarity reasons.

I'm not so familar with perl modules, so excuse the (maybe) dumb 
questions :)
Is it really needed to build the perl modules during installation?
And is it possible, that a module doesn't interpret the PREFIX flag 
"polluting" /usr/lib/perl5?

Are there any dependencies caused by N::P up to now?

matthias