[Nagiosplug-devel] Extra opts help text

[Ton Voon]

On 16 Apr 2010, at 04:24, Thomas Guyot-Sionnest wrote:

> I was thinking of doing them both but thanks! (I couldn't have  
> released
> N::P without you anyway...)

Shall I sort out access for you? Holger has access to upload to CPAN,  
but I'm fine with you having access as well.

> BTW, I might have mentioned it earlier... I've always felt it was  
> wrong
> to bundle a tar file in revision control... Those applications are
> really meant to work with "differences" and I see a tar file as "an
> undiffable bundle of differences"...
>
> I think the most "correct" way would be a git subproject while OTOH I
> agree that this raises again the entry bar for developers... So I  
> though
> maybe a better solution would be a make dist kook that downloads N::P
> from CPAN.

>
>
> The end result sounds much better: the module is included in snapshots
> and released without cluttering the source control with blobs  
> (upgrading
> the version is done by updating the link in Makefile.am)! For whoever
> else then need it (i.e. developers) they can figure out how to  
> download
> it or install it from CPAN.
>
> What do you think?

I don't have a problem with a git subproject as long as it is clear  
how and where to make changes. However, a git subproject wouldn't  
solve the "dependent perl modules" problem.

I'm not keen on auto download from CPAN because that means the version  
of N::P is decided at dist time and is not recorded. At least with the  
tarballs, we know exactly which version of N::P is included with which  
particular np. Also, dependent modules would be updated underneath you.

Then again, if someone was installing nagiosplug and N::P  
independently, there'd be no version dependency checking either.

I think the tarball is a better way. Don't think of it as "undiffable"  
differences, rather as recording the name and versions of dependent  
libraries.

If you truly want "diffables", then you would extract each perlmod  
tarball and commit those instead. That's a valid approach, at the cost  
of more files that are not maintained by us (by I guess no different  
from libtap or gnulib files).


>
>
> Next step would be choosing the download client to use... wget is  
> pretty
> much the standard IMHO... Most systems have curl as well, and since  
> it's
> about Perl stuff there is also lwp-download (or our own code using
> perl's LWP module) which is pretty standard on any system that has  
> Perl
> installed. What would you be most comfortable with?

It's more complicated than that. You'd have to download N::P, look for  
the dependency list, download those, look for their dependencies,  
continue recursion, etc. You'd end up with something like cpan (the  
command line tool/module).

Ton