On Tue, Aug 24, 2004 at 11:35:28AM -0500, Tim Kelley wrote: > On Tue, Aug 24, 2004 at 10:18:08PM +0800, John Summerfield wrote: > > Seems to me the idea of creating configuration files on the fly is > > broken. I much prefer this: > > Yes, so how exactly, for example, is phpmyadmin supposed to touch files, > such as httpd.conf, so that it works and is properly configured *when > it is installed*? Hmm? If httpd.conf was "owned" by apache, no other > package could touch it (I think we all agree allowing this would be a > mess), how can it modify the file to allow itself to work? The is why > some configuration files are created upon installation and not owned > by any package. > > So we have a tradeoff. I prefer having to do a little hunting to > figure out which package created the file than, as on a SuSE or Red > Hat system, have completely misconfigured software all over the system. > > You ignore the fact that almost all red hat packages, when installed, > are broken. I think that is a far bigger problem. You are forgetting > that Debian has taken the packaging system far, far beyond anything Red > Hat or SuSE have done. >
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. -- Paul E Condon [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]