[ 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 z...@{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
signature.asc
Description: Digital signature
