Manoj Srivastava wrote:
> It has been brought to my attention that there are a number of
> packages that violate current policy with regards to conffiles, and I
> do not think there is a reason to do so. I shall file bugs forthwith
> unless there are compelling objections to doing so.
3.3.7. Configuration files
-------------------------
Any configuration files created or used by your package should
reside in `/etc'. If there are several you should consider
creating a subdirectory named after your package.
It is almost certain that any file in `/etc' that is in your package's
filesystem archive should be listed in dpkg's `conffiles' control area
file. (See the *Debian Packaging Manual*).
This is speaking of "configuration files", not "conffiles". I would define
these two terms as:
configuration file:
any file which is used by a program for configuration purposes
conffile:
any file which may be changed, by the user, or by a program, and
which needs to maintain state across package upgrades.
Note this this use of "configuration files" is identical to that used by the
fsstnd:
3.4 /etc : Machine-local system configuration
/etc contains configuration files and directories, which are local to
the current system.
Notice that this means that /etc/resolv.conf is a configuration file,
although it is not currently a conffile. Also, this means that /var/lib/games/*
are conffiles, though they aren't configuration files. I believe it's useful
to maintain this distinction.
If you reread the policy in this light, I belive the purpose of section 3.3.7
is to say that all configuration files go in /etc, meaning that debian does
not use /usr/etc, which is an alternate location for conffiles laid out in the
FSSTND. In other words, section 3.3.7 is clarifying the FSSTND.
> For the vast number of high scores files: Do *NOT* make the
> score files conf files, instead, in the postinst, touch the score
> highfile and set the correct permissions, and delete the file while
> purging in the postrm. OK?
This doesn't work for many games which use binary formatted files as high
score files, and require the file to exist and have a valid format before
the game will run. This also doesn't address a way to cleanly handle the
case where a games's high score file format changes. If it's a conffile,
then dpkg will prompt you to replace the old conffile with the new file in
the new format. If it is not a conffile, you have to manually handle this in
the postinst.
> Also, App defaults are *NOT conffiles.
Agreed.
> conf file in bin directories!!
> ______________________________________________________________________
> tob.conffiles:/sbin/tob
> wmaker.conffiles:usr/X11R6/bin/wmaker
Yes, these are horrid. /usr should be mountable read only, which means no
conffiles should go there.
> ======================================================================
> Put these somewhere in /etc/default/root.bashrc and so on, and copy
> them to /root in the postinst, unless the files are already
> present. If files present, put a notice on the screen. These should
> not be conffiles
> ______________________________________________________________________
> base-files.conffiles:/root/.bash_profile
> base-files.conffiles:/root/.bashrc
Oh yes, let's re-implement dpkg's conffiles handling so we can strictly
interpret policy to say conffiles only go in /etc! That's absurd. We have a
fine handling of conffiles already built into dpkg, why on earth should
packages be forced to reimplement it?
> ======================================================================
> Can I say, /etc/named/?
> ______________________________________________________________________
> bind.conffiles:/var/named/named.root
> bind.conffiles:/var/named/named.local
> bind.conffiles:/var/named/named.rev-local
Some sites may have many megabytes of data in here. Some of this data may
change constantly, without the admin having anything to do with it. (Think
secondary name servers.) It clearly belongs in /var, quoting the FSSTND:
5. The /var Hierarchy
/var contains variable data files. This includes spool directories and
files, administrative and logging data, and transient and temporary
files.
/var is there for a reason. You're strictly interpreting policy to mean that
a whole load of files which the authors of the FSSTND intended to go in
/var, be moved to /etc. The result will only be a huge, bloated /etc, with
many files in it the admin will *never* modify, including binary files the
admin *cannot* easily modify.
--
see shy jo, annoyed at the trend towards a strict interpretation of policy
