Christian Schwarz: > My suggestion of tagging the files as conffiles was thought as a solution > to your problem, if the files change. The problem scenario: Version 1.0 installs an app-defaults file. It defines resource ``*Background: black''. Admin installs version 1.0. She changes the app-defaults file to ``*Background: white''. Version 1.1 is released. The app-defaults file is the same as in 1.0. Admin installs 1.1. What should be done with the app-defaults file? If the app-defaults file is marked as a config file, then dpkg asks whether to keep the current file, or to replace it with the one from 1.1. Admin keeps current file, because it does what she wants. So far, so good. Second scenario: Version 1.2 is released. The app-defaults file adds a new resource, ``*enableDWIM: true''. Application will work if this resource is missing (and defaults to false), but not nearly as well. System still has the admin-modified file. Admin installs 1.2. What should be done with the app-defaults file? Again, dpkg will allow the same choice as before. Admin chooses to keep the current file. To make the application work well, she has to compare the current file and the one in 1.2 (dpkg saves it in the same directory, so this is easy), and make some more edits. It's a small problem, but not too bad, since the changes between 1.1 and 1.2 were small. It'd be nicer if the admin wouldn't have to do any manual edits, but we can live with this. Third scenario: Version 1.3 is released. It adds a new resource, ``*importantThing: foo''. If this resource is not set, the application will crash. This is documented only in the middle of a five thousand line manual page. The package maintainer did not know this, because everything happened to work for him. The app-defaults file has been rearranged to make it easier to understand. Admin installs 2.0. What should be done with the app-defaults file? This time the differences between the currently installed and the new app-defaults file are huge. The output of `diff' is not easy to understand, and the admin makes a mistake and assumes that nothing important has changed, just the arrangement of the file. She does not add the new resource. Application crashes. Not so good. The Debian solution is to add a new file, /etc/X11/Xresources, which is used in addition to the app-defaults files and each user's own ~/.Xresources file. This way, the app-defaults file does not have to be a config file. The package maintainer can make any changes as is necessary. The admin makes any local configuration in /etc/X11/Xresources. Everyone is happy. Now that I've been made aware of this, I think it's a good solution. -- Please read <http://www.iki.fi/liw/mail-to-lasu.html> before mailing me. Please don't Cc: me when replying to my message on a mailing list.
Attachment:
pgpmd95NeMauq.pgp
Description: PGP signature