[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dh_config_model_upgrade: package upgrade with Config::Model



Le vendredi 4 décembre 2009 17:48:00, Stefano Zacchiroli a écrit :
> Well, reading your posts I understand there is in fact a
> misunderstanding. The question mentioned in the reported wiki page has
> nothing to do with a debconf question: is the question posed by dpkg
> when there is a mismatch between an on-disk configuration file and the
> old version of the maintainer configuration file. Try re-reading the
> wiki page with that in mind to see if it makes a bit more sense (it does
> to me at least).


Well, I may have not been very clear about debconf usage with Config::Mode in 
the Wiki.

I see 2 ways for Config::Model to use Debconf:

1. As proposed in the beginning of this thread, use debconf to ask a global 
question whether to use Config::Model or not. As mentioned by Stefano, this is 
a good idea. I agree (now) so I'll remove this part

2. Use Debconf to query missing configuration data (i.e. a mandatory value 
without default value). But we're not there yet.
 
> > Where is the Model?
> > Who designs the Model?
> 
> These are question I've posed my self already in the thread. Again, can
> we please leave the proposer the time to reply to those? Merely
> repeating the questions will not help :-)

In this case, the Model can be written by the upstream project, or by the 
packager. But each model is dedicated to an application. I grant you that's 
quite an effort, but not much more than writing a lens for Augeas. An Augeas 
has already quite of lot of lenses written by the community. So this kind of 
effort is possible by the same kind of community. Now, it's up to me to 
convince this community that providing configuration upgrade ( and 
configuration GUI ) is worth the effort. 
 
> > 'Model' seems to be a completely misleading use of terminology. Why was
> > it chosen?
> 
> I believe the author is using the model term in the same it is used in
> model-driven engineering [1]. *If* it is the case (I don't actually know
> if it is, but with that assumption in mind the terminology makes sense),
> a model is essentially an "abstract syntax tree"-like representation of
> a specific configuration file. Furthermore, classes of configuration
> file have a grammar in common (or "meta-model", in MDE terminology).

A model for Config::Model is to a configuration file what a schema is to an 
XML file: a description of the structure and constraint of the semantic data 
of the file. 

That's big talk. So here's a very simple example extracted from Sshd model. 
This example describes the TCPKeepAlive parameter:

'TCPKeepAlive' =>
   {
     'value_type' => 'enum',
     'help' => {
              'yes' => 'Send TCP keepalive messages. The server will notice if 
the network goes down or the client host crashes. This avoids infinitely 
hanging sessions.',
               'no' => 'disable TCP keepalive messages'
               },
     'upstream_default' => 'yes',
     'type' => 'leaf',
     'description' => 'Specifies whether the system should send TCP keepalive 
messages to the other side. If they are sent, death of the connection or crash 
of one of the machines will be properly noticed. However, this means that 
connections will die if the route is down temporarily, and some people find it 
annoying.  On the other hand, if TCP keepalives are not sent, sessions may 
hang indefinitely on the server, leaving "ghost" users and consuming server 
resources. This option was formerly called KeepAlive.',
      'choice' => ['no','yes']
    },


> > Is the model package specific or system-wide?
> 
> According to the above assumptions, a model is just an abstract version
> of a specific config file, with some specific data in it. 
> A meta-model is specific of a whole class of configuration files (e.g. 
fstab, apache conf-file, postfix map file, etc.).

A configuration model is like a set of Class definition in C++, and the 
configuration tree is an instance of the root class in the model. There are 
like a set of configuration objects arranged in a tree structure from the 
model (the set of classes)

All the best

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont


Reply to: