Jonathan Nieder <jrnieder@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>