conffiles versus configuration files
I'm dismayed that this discussion is still going and that I'm having
to post. Here is my view (Dale is right, btw.):
1. `conffiles' are files which are (a) included in the `filesystem
tree' part of a .deb file and (b) listed in the `conffiles' file in
the control area part. These are treated specially by dpkg (see the
programmers' manual or whatever it is nowadays for details); broadly
speaking the effect is that if only one out of the package maintainer
or the sysadmin changes the file then the changes will be honoured
whoever produced them, but if both do the sysadmin is prompted and has
to fix it themselves. dpkg will take care of not overwriting the
sysadmin's changes, and will remove the file automatically on purge.
1a. This is the _only_ meaning of the word `conffile'.
`X is a conffile' =/=> `X is a configuration file' and
`X is a configuration file' =/=> `X is a conffile',
although most conffiles are configuration files and many configuration
files are conffiles.
2. It is already policy that scripts may not modify (or do anything
else to, apart from read, I suppose) conffiles.
3. Configuration files can be handled in one of two ways:
3a. As conffiles. This is only appropriate if the same version of the
file will do for everyone as a default, but some system administrators
may wish to change things for themselves. In this case maintainer
scripts (or anything else other than the individual sysadmin) may not
modify this file.
3b. As script-handled configuration. In this case the file(s) should
NOT be in the package archive and should NOT appear in the `conffiles'
control area file. If the existence of a file is required for the
package to be sensibly configured it is the responsibility of the
package maintainer to write scripts which correctly create, update,
maintain and remove-on-purge the file. These scripts must be
idempotent (ie must work correctly if dpkg needs to re-run them due to
errors the first time), must cope with all the variety of ways dpkg
can call maintainer scripts, must not overwrite or otherwise mangle
the user's configuration without asking, must not ask unnecessarily,
etc. etc.
These two styles of configuration file handling MUST NOT BE MIXED, for
that way lies madness (the sysadmin will go crazy, and I'll get mad at
you).
In certain cases it is useful for 3b for there to be an `example' or
`template' file which the maintainer scripts use. Such files should
be in /usr/doc if they're examples or /usr/lib if they're templates,
and should be perfectly ordinary dpkg-handled files (not conffiles).
4. In rare cases it may be appropriate for some non-configuration
files to be handled by the dpkg conffiles mechanism. It is up to the
package maintainer to determine when this is the case.
Note, however, that if changes to the file need to be made for the
purposes of configuration then it is a configuration file and needs to
be in /etc, and handled as 3a or 3b above. For example, a script
which embeds configuration or policy information (like
/etc/init.d/rc.boot or whatever it's called nowadays) must not be in
/usr but in /etc, so that (for example) it is backed up together with
/etc when the sysadmin decides to back up their config.
If changes to a file are reasonably infrequent, either by the
sysadmin, or the package maintainer, and are not for the purposes of
configuration, it might be appropriate for the file to be in /var (for
example) and be marked as a conffile.
Such cases should usually be discussed here first.
(This possibility exists because the dpkg conffiles mechanism is
semantics-neutral. dpkg does not care what the file's contents mean
and how they are used; it just handles updates to the file in a
particular automated way. This automatic way happens to have been
designed for configuration files.)
Ian.
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: