[ reordering some quoted text ]
On Fri, Dec 04, 2009 at 04:04:04PM +0000, Neil Williams wrote:
> So it claims but that still doesn't make sense. Merely repeating the
> statement without supporting the assertion doesn't help.
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).
The source of the confusion is probably the detailed debconf mention
(which was unrelated and IMO unnecessary) in the proposer mail at the
top of this thread.
> 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 :-)
> '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).
[1] http://en.wikipedia.org/wiki/Model-driven_engineering
> 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.).
> Why bother in the first place?
<snip>
> Just what is the problem that this is trying to solve? Is it the
That, on the contrary, I feel is quite clear.
Right now, dpkg only knows about byte to byte equivalence among
different versions of the same configuration file. Hence I can be adding
a completely useless space to a conffile and dpkg will bother me at the
next upgrade, because it cannot distinguish among "meaningless" and
"meaningful" changes.
If you have a model of the old and of the new conffile, then you can
perform a more structured comparison, which ignores all semantically
irrelevant details.
The proposal apparently goes even further, and attempt some kind of
"semantic" merge between changes performed with some sysadm tool and
maintainer changes. Whether this merge is dumb or programmable by the
maintainer is another question I've already raised in this thread.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
Attachment:
signature.asc
Description: Digital signature