[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#348336: I'm really confused by section 10.7.4 in the policy

Nicholas Bamber <nicholas@periapt.co.uk> writes:

> Second paragraph: "The maintainer scripts must not alter a conffile of
> /any/ package, including the one the scripts belong to."  This statement
> can be construed as prohibiting any automated generation of
> configuration files, and any user interaction with the construction of
> the configuration file via debconf.

Only if one confuses conffiles and configuration files.  That distinction
is extremely important to understand Policy in this area.  They are two
different things, although in general conffiles are a subset of
configuration files.

We can probably make the distinction between the two concepts clearer.

> Fourth paragraph: "If it is desirable for two or more related packages
> to share a configuration file /and/ *for all of the related packages to
> be able to modify that configuration file*, then the following should be
> done:"  This statement contradicts the second paragraph.

No, it doesn't, but again because it's talking about configuration files
that are not conffiles.

> As far as I can see if package A installs file pregenerated X where file
> X was originally installed by package B and where A's control file has a
> "Replaces: B" clause, then the system will know that file X is now owned
> by package A.

If by "pre-generated" you mean that the file is contained in the *.deb,
that's correct.

> However if package A modifies file X, for example by using "sed", the
> system has no way of knowing that the file is now owned by package A.

That's also correct.

> I suspect that this might be what the policy section is attempting to
> express, but it is not at all clear.

Well, no, Policy isn't trying to describe that, as that's more of a detail
of how dpkg tracks file ownership.  Policy is instead trying to state what
you can and cannot do with conffiles and configuration files to provide a
set of guarantees that other parts of the system rely on.

> Sixth paragraph: "The owning package should also provide a program that
> the other packages may use to modify the configuration file."  I suspect
> that a good example of this might be the "passwd" package which provides
> utilities such as "useradd" to modify its configuration files.

Yes.  update-inetd is another example.

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Reply to: