Nicholas Bamber <nicho...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
