Re: Clarification of Policy and Packaging manuals requested
On 24 Feb 1998, Manoj Srivastava wrote:
> Hi,
>
> Could I get an interpretaion of the policy on this message,
> point by point? (I mean that. I have put thought into these
> questions, I merely ask for the courtesy of some thought in the
> responses). Please pardon the redundancy, I think I feel strongly on
> this issue.
Ok. Here you go...
> >>"Christian" == Christian Schwarz <schwarz@monet.m.isar.de> writes:
>
> Christian> Let me just throw in a few notes:
>
> Christian> 2. I'm wondering why it's so hard for people to get the
> Christian> difference between configuration files and
> Christian> conffiles.
>
> Perhaps because these terms are never defined, and one of the
> obvious interpretation is said to be wrong?
True. I think the term `conffiles' isn't very good. Perhaps it should be
called `modifiable-files' or something like that. (But anyways, I'm sure
we'll not rename this term now. Thus, we'd have to document the `correct'
interpretation somewhere in the manuals.)
> Christian> Perhaps, the name "conffiles" is not a good name
> Christian> (but either way, it's unlikely that we'll change the name
> Christian> because this would be a _lot_ of work). Here is my
> Christian> understanding of these two terms:
>
> Christian> conffiles (CF): a file that is listed in the `conffiles'
> Christian> control file of a binary package (.deb)
>
> Oh, cool. Anything we call a conffile is defined to be a
> conffile.
>
> This is a circular definition.
No. Actually, I was thinking of saying `a conffile is a file which is
listed in the conffiles file' :-) (Note, the singular and plural in the
two cases :)
But the main point is: A file being CFGF is a characteristic which is
defined by the program which reads the file, while being CF is just a
certain `label' the maintainer puts onto a file to tell dpkg to be
carefully when upgrading that file.
> What is the criteria for putting the name of the file in a
> conffile definition, then?
I'm thinking of the following criteria:
1. The file is usually modified by the system administrator.
2. It's legal to modify that file according to the FSSTND.
3. The package provides a `default version' of the file.
According to #2, all CFs must be in a `writable' directory like /etc, or
/var--no CFs may be in /usr, for example.
#1 tells us that any `static' files don't need to be tagged as CF. For
example, there is no need to tag /bin/bash as CF, since the sysadmin is
not expected to modify this file. (This special case isn't allowed by #2
either.)
Furthermore, there is no need to label pure dynamic data (as most files in
/var/spool or /var/log, for example) as CF, since we don't provide default
versions for these files (that's #3). This is because dpkg doesn't know
about these file (since they are not included in the package) and thus
dpkg doesn't care about these files when upgrading the packages. Note,
that with that, the maintainer has to take care of removing the packages
herself, for example, via the postinst script.
> Why should all CFGFs included in a package
> (that is, not manipulated in postinst) not also be CFs?
A file being CFGF does not imply that it's only for humans: sometimes, we
have scripts which also modify CFGFs. For example, /etc/inetd.conf is
currently maintained by a script (update-inetd) _and_ by the user (note,
that this will be a policy violation as soon as I release the next policy
manual). If we would tag such CFGFs as CF, the user might be queried
during package upgrades about what to do with the changed CF but perhaps
she didn't change anything herself (since everything has been done by
maintainer scripts automatically) or she doesn't know what this file is
about!
Note, that this interpreter is very young: current policy does not
restrict a CF to be only maintained by the sysadmin (and not by scripts).
We'll discuss this in the next policy weekly posting.
> Why should
> all scripts not be CF's? Indeed, why should every file not be a CF?
The point is that a file being CF means a lot of `overhead' for dpkg.
Since we follow the FSSTND and assume that the sysadmin also follows the
FSSTND, we can assume silently that any files provided by our packages are
not changed by the system except for CFs. So tagging everything as CF
would just be wasted resources.
(Note, that there are other possibilites to change non-CF files in
packages, for example, via dpkg-divert.)
> Does the program behaviour change when the conffile changes?
> if not, then why care about whether it is changed or not? I mean, if
> nothing changes, ignore/delete the file.
Huh? Sorry, I didn't get that.
The program's behaviour changes _by definition_ if the CFGF is changed.
> If the program behaviour changes when a CF is changed, and it
> is supposed to be edited locally, why is it not a configuration file?
> Seems to fit the description given below.
Did you swap the terms CF and CFGF here? (Or am I failing completely now?
:)
> Christian> configuration file (CFGF): a file that may be changed by
> Christian> the local system administrator to adjust a program to her
> Christian> needs
>
> And conffiles are not?
That's another story.
It's true, that most CFGFs are CFs, but there might be exceptions: Tagging
a file CF is just to tell dpkg to take special care of the file during
upgrades. However, the package might implement its own `CF mechanism'
which might be adjusted for the special case of the package. In this case,
the CFGF would not be tagged CF.
(The other question would be: Are there CFs which are not CFGFs? I can't
think of any examples... :)
> So, conffiles are not meant for the local sys admin to change
> to modify the behaviour of programs?
(Sorry if I repeat my arguments. But you wanted a _detailed_ reply ;-)
Again, CF does not say anothing about the contents or use of the file.
It's just to tell dpkg to be carefully during upgrades.
> Why do we have them there at all? why are all CFs not also CFGFs? The
> definitions presented here indicate that should be the case
Yes, I guess all CFs are CFGFs. (But not the other way around!)
(BTW, I just noticed that current policy is really all screwed up WRT
CF/CFGFs. I'll fix this with the next release--as soon as we have a
consensus about the right terms and policy.)
> Christian> Clearly, these two things are not the same.
>
> I'm afraid this is not clear at all.
Is it clear now (with the answers above)? If not, ask again. (I still
think that this should be clear.)
> Are these terms mutually exclusive? Are they orthogonal?
They are not mutually exclusive. I guess in most cases, a file is CF and
CFGF at the same time.
The criteria of the terms are `orthogonal', since CF is a `label' and CFGF
is a `characteristic.' However, since in practise these two aspects occur
at once, they don't look very `orthogonal'. But I think they are
`independent' :) (Hope, that these mathematical terms don't raise more
confusion as we already have! ;-)
> I don't want to loose any changes made to my packages configuration
> files, so are they not all conffiles?
There are other ways to make sure the changes are not lost: Don't include
the CFGF directly in the package tree and control any changes via the
maintainer scripts.
I guess that this is the correct solution for CFGFs like the disk images
shipped with dosemu: the images are not in text format, so it is hard for
the sysadmin to decide which file to use after an upgrade. Perhaps the
maintainer scripts could extract some more info about the actual
differences and present these to the sysadmin during the upgrade
automatically?
> why are all conffiles also not configuration files?
I guess they are (or at least, should be :).
> What is the rationale behind a distinction between configuration files
> and conffiles?
(I think this should be clear from my above statements. If not, just ask
again.)
> Why are conffiles not a proper subset of configuration files?
I think they are.
> Should we be concerned about sysadmins changing scripts all
> over? should scripts in /var/lib/dpkg/methods be conffiles ``in
> case'' the local sysadmin changes them?
I think we can rely on FSSTND here: We can assume that the user does not
change anything below /usr (except the files in /usr/local, of course, and
modulo any dpkg-divert calls).
However, as it has been pointed out a few times before, dpkg does not
follow FSSTND itself :) These scripts would actually belong into
/usr/lib/dpkg. Thus, we can assume that they are not changed even though
they are in /var ;-)
> Christian> 3. Whether a file is a CFGF should be clear by looking at
> Christian> the purpose of the file/program.
>
> The weekend long debate should amply demonstrate that it is
> not clear at all.
Huh? For example, lintian reads a file /etc/lintianrc for getting its set
up. So this file is clearly a CFGF. (But now, we could start to discuss
whether /usr/bin/lintian is a CFGF too 8-)
> Christian> Whether a file should be tagged as CF, should also be
> Christian> clear: files should be tagged as CF if the file is included
> Christian> in the package tree (i.e., displayed by looking at `dpkg
> Christian> -c') and if any possible changes done by the local sysadmin
> Christian> should be preserved during package upgrades.
>
> I think this definition fits CFGF as well. Or do you mean that
> DFGF files should not be changed by sysadmins? Or we can blithely
> throw away changes to CFGFs?
(What's DFGF? Debian-figuration file? ;-)
(I guess I should stop here and give you time to reply. Otherwise, I'll
repeat the same statements all over again...)
Since CF is a subset of CFGF, this definition carries over from CF to
CFGF.
> Since this fits both sets of files, this is not a good
> defining/distinguising criteria.
Right. See the revised criteria above.
> It seems to me that all CFGFs should be CFs, unless they are
> not included in the package. The converse is the matter of
> dispute. Are all CFs also CFGFs?
>
> But, if the terms are mutually exclusive (I do not think they
> can be, as the rest of this paragraph shall show, I hope), and CFs
> are not CFGFs, CFs can be anywhere in the file system, right? So if I
> do not want to change my config file to go into /etc, I can just call
> it a conffile and leave it in /usr/lib? Why not? will it violate
> policy? So the terms cannot be mutually exclusive.
>
> Or are you saying a file can be both CF and CFGF,
Yes. In most cases, it is.
> Christian> Comments are appreciated. If you think that some sections
> Christian> in the manuals should be clarified, please tell me exact
> Christian> sentences which you find `confusing'.
>
> It is not any sentence present that is confusing, it is the
> ommission of a criteria (or a non circular definition of conffile, or
> a clear distinction between a conffile and a configuration file.
Ok. As soon as we have a consensus about the criteria and the use of these
terms, I'll try to fix the manuals.
I hope my answers clarified the whole topic. If not, feel free to ask.
(However, it might be good to remove the lots of duplicated
questions/answers above. I think there are only a few basic questions we
are talking about.)
Thanks,
Chris
-- Christian Schwarz
Do you know schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
Debian GNU/Linux? schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA
http://www.debian.org http://fatman.mathematik.tu-muenchen.de/~schwarz/
Reply to: