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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
