On Fri, 04 Dec 2009 13:29:28 -0300 Felipe Sateler <fsateler@gmail.com> wrote: > > Where is the Model? > > > > Who designs the Model? > > You (or hopefully someone else who had the same config file syntax). Then it's a config file parser, not a modeller? > > Is the model package specific or system-wide? > > File specific. So why not just fix the package to handle the config file intelligently? > > Why bother in the first place? > > Because a diff is rather useless for people who don't know what a > config file is. That's an argument for fixing the package to allow intelligent upgrades to it's own config files, not an argument for adding another layer to the postinst. My problem with this is that it's fixing the wrong problem. 1. packages shouldn't need the user to look at a diff unless that user is likely to be a sysadmin who would understand it. i.e. a diff is only used when the user has made such changes to the file that no other parsing can fix things. If the user hasn't modified the file themselves, no package changes should leave the conffile in a sufficiently bad state to need an extra parser - that's a bug in the package, not a reason to implement a whole new approach. 2. If this can't be done, just don't update the config file and get the application to complain or fix things. Adding more work to the postinst is just going to make life harder. > > Just what is the problem that this is trying to solve? > > That people, when faced with the standard question by dpkg of conffile > updates, will adopt the "hmm.... just click enter?" attitude "so > common in the Windows world". Wrong place to fix that problem IMHO. Solve it before it gets to this stage or delay until the app needs to use the config and then it can complain or fix things directly. No model understands the config file as well as the application itself. Creating yet another interface is not a solution. > > Is it the > > packages themselves or some "model" of what the system should be > > configured to resemble? > > The model is a description of the syntax of a configuration file. That > way, config::model can read both on-disk and new conffile, abstract > out any irrelevant changes (like whitespace), and then decide how to > do the merge. Sounds as if you're trying to implement a quilt or git interface onto conffile management when the idea would be better framed to prevent the need for such an interface in the first place. > > If it's the packages, why not just get the packages to explain > > themselves more clearly in their debconf questions? > > It is the standard conffile upgrade question that is being avoided. No, it's being wrapped. Avoiding it would mean that the conflict wouldn't be left for dpkg to resolve at all. > > How is the model to be translated? How are the strings used by the > > model to be translated? Who is in control of when those strings are > > changed? > > > > Why would a model be any clearer than the package-specific messages? > > (Unless it stays out of the way entirely and is just an overgrown > > system of defaults.) > > > > How is a model meant to make sense to a user when the detail does > > not? > > > > Why add yet another layer? > > > > 'Model' seems to be a completely misleading use of terminology. Why > > was it chosen? Those questions need answers too, BTW. *Especially* those related to i18n. > > debhelper is a build time package, why use it dh_ styles for an > > installation based system? > > dh_ is used at build time. It sets up .config and postinst, like other > dh_ commands. That didn't appear obvious from the initial messages. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpGn8UgaTsXj.pgp
Description: PGP signature