[Nagiosplug-devel] Integrating Nagios::Plugininto the distribution

[Ton Voon]

On 14 May 2007, at 05:01, Gavin Carr wrote:

> On Fri, May 11, 2007 at 09:46:12AM +0100, Ton Voon wrote:
>> The FindBin objection is hard to overcome too. Using PERL5LIB means
>> more work for the user, setting up in various places (nagios user's
>> profile on all monitored boxes, NRPE and Nagios start up scripts) - I
>> can envisage more support calls coming from this decision. I'm not
>> entirely convinced that using FindBin is that bad either - I think it
>> is equivalent to using LD_RUN_PATH, which some Solaris people use to
>> link to openssl (though admittedly, this is a decision they make at
>> compile time, not always in the code at execution time). I guess we
>> could have an option to strip out the "use lib" lines from the
>> plugins at make time - would that be sufficient?
>
> I guess so. Though adding the code in if you're using local perl  
> modules
> seems cleaner. Maybe we just have something like this in the plugins:
>
>   # use lib '/path/to/local/lib';
>
> and uncomment and munge the lib path at install time? Is there benefit
> from doing a FindBin rather than just setting it lib outright?
> (Developers can just set PERL5LIB in their environments after all ...)

That is starting to look a lot like the current utils.pm, which  
always seemed to give problems to the plugin scripts searching for  
this module.

The advantage of FindBin is that N::P can be found relative to the  
script. This helps with cvs because, for instance, I have nagiosplug  
project checkout into ~/np, so the scripts exist in plugins-script  
and should be able to locate N::P as relative to this directory. Yes,  
you could use PERL5LIB, but then if you have to change this variable  
if you have differing versions of nagiosplug exported (I have a ~/np/ 
nagiosplug_r1.4 that I use for reference).

So from a dev point of view, I think FindBin is better. I think this  
philosophically makes sense to strip it out at compile time, as we  
use other tools (autoconf, automake, *.in files) that are easier for  
developers, but then make changes for compile/install time.

The other way of looking at it is that keeping it in doesn't cause  
problems if you do not install N::P locally, but if you forget to add  
it in, the perl plugins will fail.

>> I agree with Thomas that we always install N::P locally, though we
>> provide configure switches to turn off.
>>
>> Is it fair to say we should proceed with the current plan?
>
> Sounds like it.

Excellent. I'll take a look at Module::Install::Bundle and see if we  
can create a bundle based on N::P to include in the dist. This will  
start after the 1.4.9 release.

Ton

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