Re: Is adding dh_config and a postinst snippet ok ?
Raphael:
I'm not *too* familiar with either tool, but hopefully my limited
understanding is sufficient to answer your question.
Disclaimer: I don't use either module, though I have worked somewhat
with augeas, so I'm aware of its limitations. Namely, ML programming
can be hard for beginners (steep learning curve), and is very close to
what you might get from yacc/lex (a way of specifying a grammar
similar to Backus-Naur Form)
On Mon, Jul 20, 2009 at 12:00 PM, Raphael Hertzog<hertzog@debian.org> wrote:
> On Mon, 20 Jul 2009, Dominique Dumont wrote:
>> I'd like to add the following files in libconfig-model-perl:
>> - /usr/bin/dh_config
>> - /usr/share/debhelper/autoscripts/postinst-config-model
>>
>> In short, the goal is to use these files to perform smooth upgrade of
>> configuration data during package upgrades. See [1] for full details.
>>
>> But we're not there yet.
>>
>> Before deciding whether dh_config is a good idea or not, I want to check
>> that these files will not break anything just because they are installed
>> on your file system.
>
> It should not AFAIK. dh doesn't call random dh_* scripts, you need to ask
> it explicitely "dh --with config-model $@" and you need to provide
> a /usr/share/perl5/Debian/Debhelper/Sequence/config-model.pm file.
>
> That said dh_config is probably a bad name, it's too generic IMO.
> dh_config_model ? dh_install_config_model ?
>
>
> A question about this project, I've recently discovered augeas, how do you
> compare yourself with it?
Augeas lets you parse configuration files by creating a lens, which
then lets you write them back out. You write a lens using regular
expressions, mostly. The problem is that it doesn't do much validation
of what you give it -- usually, for the sake of brevity, you tell it
something like "a keyword is a string of characters, a-z." It then
brings that info in and lets you access it using the appropriate tree
address (sort of like a UNIX path)
Config::Model is different because it provides an easy way to also do
validation on what you give it, based on the rules (the "configuration
model" itself). Config::Model is also based in Perl, which makes
writing such rules (even complex ones) easier than doing it in ML, and
it can check things like "make sure some_integer_variable is between 0
and 10" or whatever other boundaries restrictions you'd like.
>From the perldoc:
Each configuration class declaration specifies:
* Most importantly, the type of the element (mostly leaf, or node)
* The properties of each element (boundaries, check, integer or
string, enum like type ...)
* The default values of parameters (if any)
* Mandatory parameters
* Targeted audience (beginner, advance, master)
* On-line help (for each parameter or value of parameter)
* The level of expertise of each parameter (to hide expert
parameters from newbie eyes)
I see these two tools as complementary, rather than competing,
technologies. You can use the data parsed via Augeas (which to me
seems like more of a lexer/tokenizer part, kind of like what yacc/lex
do) to get data from the file using a grammar. Then you need some
code, which is provided easily through Config::Model, to actually
validate what you've got, make sure it all makes sense (for example if
you're trying to parse XHTML, then to make sure certain elements like
<p> are inside <html>). I suppose you could also write such code
yourself, but then you'd need to write both accessors and mutators to
do that sort of validation, which I imagine is something Config::Model
does on your behalf.
Finally, it should be noted that Dominique is the maintainer of both
modules, so he wouldn't have packaged them both (and went through all
the trouble of writing Config::Model in the first place) if there
wasn't a good reason :-)
But I'll leave it to him to correct my understanding here.
Reply to: