[Nagiosplug-devel] Extra opts help text

[Thomas Guyot-Sionnest]

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

On 15/04/10 04:17 AM, Ton Voon wrote:
> 
> On 13 Apr 2010, at 22:51, Thomas Guyot-Sionnest wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 13/04/10 01:14 PM, Ton Voon wrote:
>>> Hi!
>>
>> Hi Ton,
>>
>> Nice to see you!
> 
> Sorry, not been around :(
> 
>>> I wanted to get some opinions about the --extra-opts help text. In the  
>>> C code it reads (with typo):
>>>
>>> --extra-opts=[section][@file]
>>>   Read additionnal options from ini file
>>>
>>> [further down between notes and example]
>>>
>>> See: http://nagiosplugins.org/extra-opts for --extra-opts usage and  
>>> examples
>>>
>>>
>>> However, the Nagios::Plugin library says:
>>>
>>>  --extra-opts=[<section>[@<config_file>]]
>>>    Section and/or config_file from which to load extra options (may  
>>> repeat)
>>>
>>> Note a difference in syntax. I'd like to harmonise these and make it  
>>> more readable.
>>>
>>> A colleague says that "additional options" or "extra opts" suggests  
>>> there are other options not available through the command line. I  
>>> don't want to change the parameter, but I propose that the text be  
>>> changed to:
>>>
>>>  --extra-opts=[section][@file]
>>>    Read options from an ini file. See
>>> http://nagiosplugins.org/extra-opts
>>>  for usage
>>>
>>> For both libraries.
>>>
>>> Any objections?
>>
>> I fully agree. I can do it as I have a few other things to work on in
>> Nagios-plugins...
>>
>> So I will remove the notes text as well, correct?
> 
> Yes please. I'll do the N::P library and update SF's git repo.

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

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?

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?

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

iD8DBQFLx9iD6dZ+Kt5BchYRAlxPAKCsb+sDLpq4fgeQ6B6p9TLgy6YlSgCfR084
X3VHZT5zdA+EjJTt5XfamjE=
=j9Ci
-----END PGP SIGNATURE-----