Re: Problem with lprng turned out to be problem with dpkg?

[Tony Finch <fanf@lspace.org>]

Rob Browning <osiris@cs.utexas.edu> wrote:
>Michael Alan Dorman <mdorman@calder.med.miami.edu> writes:
>
>> But then _every_ maintainer has to get it right, or he or she could
>> break the system (what if they accidentally include a /tmp dir with
>> the wrong perms?), whereas now, if one maintainer gets it wrong, he or
>> she will only likely break one subsystem.
>
>I recognize that, but why would a maintainer be putting inappropriate
>*leaf* directories in their packages.  If they do, then bug reports
>get filed, and the problem gets fixed on the next package release.

To fix things properly, you would have to use a more general
definition of leaf directory than usual: for example, in the lprng
case, the directories affected are /var/spool/lpd and
/var/spool/lpd/lp.

I found another manifestation of the problem recently, of a slightly
different flavour. You can't move a directory and leave a forwarding
symlink in the old place: the console font and key map file
directories moved from /usr/lib/kbd to /uar/share, but dpkg failed to
replace the old direcotries by symlinks to the new directories,
instead leaving them as empty directories.

I think the cause of the problem is that directories aren't owned by a
particular package: every package contains /. If each directory (and
file, too) were owned by _one_ package, then dpkg could allow that
package to change it in any way, and be sure that the right entity is
responsible for the change. If a package tried to usurp another's
directory, dpkg would refuse to install it because of a conflict. If a
package contained files that belong in a directory that doesn't exist,
this would indicate an unresolved dependancy.

This is, of course, rather incompatible with existing packages :-)

Tony.