Bug#348336: I'm really confused by section 10.7.4 in the policy
Nicholas Bamber <nicholas@periapt.co.uk> writes:
> In fact my understanding was that the conffiles concept was superseded
> by the convention that everything in /etc is or should be a
> "configuration file/conffile" for some package.
The conffiles concept has definitely not been superseded. All that's
happened is that commonly used packaging tools like debhelper will
automatically mark any file in /etc as a conffile, which has meant
somewhat less developer understanding of conffiles since developers no
longer have to worry about it manually (but has also quashed a type of
common bug).
> In any case since policy sections are often cited in bug reports, it is
> clearly necessary that a developer should be able to dip into the policy
> - the commandment to read the policy notwithstanding.
> So my suggestions are:
> 1.) The section needs to provide links to (or failing that definitions
> of) all concepts used. Conffile is an obvious example of that.
10.7.1 already defines both concepts and tries to make it clear that
they're not the same thing. I'm happy to enhance those definitions if you
can point out to me what made them unclear. (Obviously I know too much
about this to be a good first reader of that section.)
> 2.) The policy should explain why it mandates the non-sharing of
> files. I think we have covered that.
In general, Policy is never *required* to provide a rationale. It's
usually for the best if it does so that we can remember why rules exist
when considering further Policy changes later, but there are a lot of
rules in Policy currently unaccompanied by specific rationale. But I'll
see if I can add something.
The reason I would write down as the rationale is fairly simple: it's a
violation of robustness to distribute across multiple packages knowledge
of the exact syntax of a configuration file and how to make modifications
to it, since if that syntax ever changes, we end up with a huge mess. If
all changes are made through scripts provided by the owner of that
configuration file, we can change the syntax of that configuration file by
only modifying one package.
There's a secondary advantage that it's easier to robustly make changes to
configuration files if force all that code to go through a single path,
rather than expecting everyone's maintainer scripts to handle various
error cases gracefully.
> 3.) The policy should provide strategies to work round the non-sharing
> of files. The policy already does this in mentioning scripts that manage
> files but falls down in not citing examples. Modularized configuration
> files as mentioned by the original requestor also achieves this, but
> this post was completely lost in the argument over /etc/profile. I don't
> know if there are any other strategies but two already demands
> enumeration.
An example would be useful, yes. I think useradd is not a bad example, so
I can add that. update-inetd is possibly going to change, so I don't
really want to add that as an example.
And yes, it would be good here, I think, to explicitly mention breaking
configuration files into loadable directories of fragments as superior to
most schemes of sharing configuration files.
> 4.) The title should be changed to "Sharing conffiles and configuration
> files". This would provide the reader with another clue that there is a
> distinction and that he needs to know it.
Hm. That reads very strangely to me, since conffiles are generally a
subset of configuration files.
> 5.) As I see it the original requestor was asking for policy to be
> loosened rather than clarified. As far as I can see there is a
> convincing case why that should be rejected.
Since then, we've actually added support for /etc/profile.d for LSB
compliance. I suspect that partly changes the original request. I do
think that the original request to encourage *.d directories in general is
a good one.
> 6.) I see a particular comprehensibility conflict with the obscure
> section D.2.5. One possible interpretation of that section is that
> conffiles are some how obsolete.
This is documentation of dpkg's internals and will be pulled out of
Policy.
> 7.) I think the should be some effort to merge #23712,
I think this is unrelated. This is about handling configuration files
that move between packages, not shared configuration files.
> #348336, #533387.
I don't think this last was the bug number you meant. That's an unrelated
bug in the wordpress package.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: