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.
pgpDDlJBVttb3.pgp
Description: PGP signature
