[Nagiosplug-devel] Integrating Nagios::Plugin into thedistribution

Vonnahme, Nathan nathan.vonnahme at bannerhealth.com
Thu May 17 21:09:43 CEST 2007


> But I'm pretty sure most people would think that's a silly idea -  
> mysqlclient is (a) too big a piece of code to bundle, and (b) is not  
> central to what the plugins is about. But N::P is on both counts, so  
> I think merits bundling with the distribution.

Just to weigh in with my opinion - I think it's an acceptable approach
to distribute a known-good bundle of libraries, so you can more
effectively support one set of things.

I deal with commercial software packages, both at the OS and application
level, that even bundle their own Perl distribution so they can have a
known, tested set of CPAN modules.  For example, the AIX tool 'suma'
relies on some CPAN modules, which all get installed in /opt from the
AIX install media.  One time I completely broke suma by upgrading a
bunch of modules from CPAN.  Of course IBM doesn't want to support my
random modifications to CPAN, and I don't want to be tied to the frozen
perl install in /opt, so I took the Perl 'configure' script's
recommendation and installed my own perl in /usr/local.

As unfortunate as the comparison is, libraries or Perl modules are
really similar to DLL files, and packaging known-good DLLs with your
application has long been one of the easier ways to avoid DLL hell.
Relying on packaging / install / dependency systems like CPAN, RPM or
Debian packages is better in a lot of ways, but I guess it depends on
your target audience.  I bet a lot of people who want to use Nagios
plugins aren't Perl experts and don't necessarily want or need to learn
how to configure CPAN and install modules just to get the plugins to
work.




More information about the Devel mailing list