[Nagiosplug-devel] Extra opts help text

[Thomas Guyot-Sionnest]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16/04/10 04:19 AM, Ton Voon wrote:
> On 16 Apr 2010, at 04:24, Thomas Guyot-Sionnest wrote:
> 
>> 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.

Right... unless we'd mirror them in git which would be really annoying,
or just require them as the other "dependencies"... Lest forget it for now.

> 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.

Not really, I was thinking of including the download link in make dist.
We could also mirror the modules in SF.net web if we fear the files
could vanish (especially true for 3rd party modules).

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

The release or shanpsote would have all the files downloaded by "make
dist" - the specific version we wanted. We can even check md5's as to
avoid releasing a broken tarball caused by some download error.

> 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.

Then as Andreas suggested, uncompressed would be much better on the git
internals.

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

Yes, that would be valid too.

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

Since we know which module we're downloading we know its dependencies
too. Just add a comment near the download link to remind of checking for
dependencies changes.

- --
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFLyEJY6dZ+Kt5BchYRAm5UAKCXEr5WkTYNCzUNUAO9PN2uz3Tl7gCgzfvd
gzSZGcGdd0kIZ76Ca2TANp4=
=5M3c
-----END PGP SIGNATURE-----