Re: RFS: confget -- read variables from INI-style configuration files
On Thursday 19 March 2009 23:12:22 Peter Pentchev wrote:
--cut--
> > It took me some time to assimilate the hardening notes at wiki.d.o [1],
> > I'm remotely familiar with, though this document is informative enough
> > about potential build and run-time failures on different architectures
> > wrt compiler/linker hardening options. Anyway, buildd logs and buglogs
> > should be monitored closely, and in case of troublesome behaviour we
> > should disable features via DEB_BUILD_HARDENING_[feature]=0.
> > The question is: is it worth the effort? Let's say, I'm fine either way
> > ;-)
>
> Well, the hardening wrapper has shown me some problems in both third-party
> software and also (very few, but still) in my own programs in the past
> couple of months, so if you're asking about whether it's worth it to
> compile with the hardening wrapper and pay attention to its warnings, then
> I personally say "hell yeah!" :) But then... confget already uses it,
> doesn't it? I'm not quite sure what exactly you mean here :)
Yes, it is the usage of hardening-wrapper what I found slightly
adventurous ;-) For instance, I'm not extremely positive whether all
compiler/linker hardening options are correctly replicated on each Debian
supported architecture, or their usage simply leads to unspecified,
unexpected or just plain behaviour. If unsupported hardening options are
silently ignored (like ld -z relro on ia64) then we are lucky, otherwise we
should fight the issue. OTOH, we can count these eventual failures as regular
compiler/linker bugs, so it might be useful at the end to reveal and report
compiler/linker issues if any. So, I agree to take the chance.
> > A couple of minor points: confget(1) manpage references to a non-existing
> > Config::IniFiles(3) which potentially should describe the syntax of ini
> > configuration files if I'm not mistaken?
>
> Erm... hmm. Actually, Config::IniFiles(3) is the manual page of
> the Perl Config::IniFiles module, available in Debian as
> libconfig-inifiles-perl - but then I guess you already knew that :)
Actually, I was not aware of that perl module ;-)
> The reason I cross-referenced it in the SEE ALSO section of the confget(1)
> manual page is not to describe the format, but to point to a different
> implementation, a different programming library that people can use to
> access INI files. Maybe it's not quite clear, and I agree that maybe,
> once in a while, it could even be confuzzling; do you think I should drop
> the cross-reference and just spell it out in words, something like
> "Another INI parser is the Config::IniFiles Perl module" or something?
Sure, SEE ALSO sections is a proper place for citing alternatives, and
detailing this is a *Perl* module would give pointers to the users (me
included).
It is still not very clear to me how to find the full configuration file
syntax specification? Moreover there is neither a Standard nor a popular
protocol which stipulates that. How are users supposed to know the gory
details about it? Note that, "Anybody has looked at some INI files in the
past" doesn't sound extremely promising ;-)
> > It would be even better to include
> > some short configuration files samples/examples in the binary package
> > itself. Your own t{1|2}.ini should suffice.
>
> Ah, examples. An interesting, intriguing concept, indeed :)
>
> I'm not sure if t1.ini and t2.ini are really suitable as sample INI files;
> they're more like silly, contrived, awful examples of the depths that
> an INI file can sink to... But I could install them as examples, if you
> think it's appropriate.
>
> I can't prepare a new package right now, but sometime tomorrow I'll see
> what I can do about uploading a new version, if you think it's worth it.
Sure, take your time. Examples are just good to have, although not mandatory.
So, the only unclear point left is the configuration file syntax
specification. This is not a hard showstopper, but would be very nice to have
in place proper.
> > Otherwise, the package looks useful and the source code very clean and
> > sound. Let me know what you think about the above points, and I'll
> > sponsor.
>
> Thanks for the time you took to examine it!
You are welcome.
--
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
Reply to: