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

[Gavin Carr]

Hi Ton,

Sorry for the late response to this thread - been out of town for
a bit.

On Mon, Apr 23, 2007 at 05:25:23PM +0100, Ton Voon wrote:
> I think Nagios::Plugin is at a state where it is good enough to start  
> using for the plugins in distribution. The main question is: how?
> 
> The current utils.pm has problems because of the parsing of the  
> location of this module. We want to fix this so it is not an issue  
> with N::P.
> 
> 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 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.

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?

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)?

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 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 did see John R's comment on site policy that _prevents_ modules
being installed to standard perl lib locations, so that's one 
possible argument. Although that policy just seems too weird to me.)

I'll comment separately on the other specifics separately, but 
wanted to clarify the requirement for (b) first.


Cheers,
Gavin