Re: dpkg / apt equivalent to 'rpm -qf'?

[Paul E Condon <pecondon@mesanetworks.net>]

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           
pecondon@mesanetworks.net