It appears that there are two distinct roles for packages with
respect to files:
1 the .deb of the package contains an initial copy of the file
2 the package programs/scripts are permitted/expected to maintain and
update the file as needed.
It is unually assumed that only one package may play either of these
roles with respect to a given file, and that it should be the same
package for a given file. But httpd.conf seems to be a counter example
for role 2. That only one package may play Role 2 w.r.t. a given file
is Debian policy only for files that are served Role 1 by that same
package. When the httpd.conf situation arises, the Debian way seems to
be that a package constructs an initial copy of the file on the fly,
rather than containing an initial copy. Thus, the file is built by
the package but not "owned" by the package.
This may sound goofy to outsiders, but it preserves the primacy of
policy while solving a practical problem. However, there is a
problem waiting for a smart lawyer to exploit: There is nothing
in these rules that precludes some arbitrary new package from touching
httpd.conf for some purpose of its own that has nothing to do with
the proper operation of a web server system. What does keep this
from happening is the good sense of Debian maintainers. Until
someone can come up with a plausible example of why it might thought
reasonable to have some other package, mutt, for example, touch
httpd.conf maybe we can avoid adding more rules to policy.
But if a new ruled are needed, consider defining groups of packages
that "own" a particular file as "tenants in common" or as "joint
tenants". The existence of these groups would have to be documented
somehow, and the programs written to maintain the documentation. It
sounds like a lot of work for very little gain.