Jonathan Nieder <jrnie...@gmail.com> writes: > My impression is that this "must" has been treated as a "should" in > practice, and I don't think it's because of the detail of wording > addressed by the first hunk of the patch below. The interoperability > problems caused by violating this piece of policy are subtle, and it's > hard to find packages violating it in an automated way.
I'm okay with those particular changes, but it does feel to me like we should clarify this even further. I'm uncertain about the differences between must and should that are left over; I think we need to figure out what we're requiring and what we're recommending in a more comprehensive way. I went back and re-read the thread, and I think Manoj makes a useful distinction between packages that share a configuration file but a good long-term solution hasn't been developed yet, and packages that don't share a configuration file but want to reconfigure other packages. I think we may want to say that the former should use a programmatic interface to handle things, and the latter either must use a programmatic interface or must not modify the configuration files and instead find some other way to accomplish their goals. (I think the discussion of what the installer does is not directly relevant. I think the installer is allowed to do all sorts of things that a regular package is not allowed to do, due to its special status as the initial configuration generator for the system.) We don't explicitly say that using a configuration mechanism that allows packages to add fragments in a *.d directory is generally superior to any of these approaches. It might be a good idea to say that. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87a9xy4rqo....@windlord.stanford.edu