Bug#134758: 'dpkg -S' and symlinks
Package: dpkg
Version: 1.9.19
Severity: wishlist
dpkg -S only compares filenames lexically: so symlinks can lead to
annoying false negatives, as in the following example:
lyonesse$ type xterm
xterm is /usr/bin/X11/xterm
lyonesse$ dpkg -S /usr/bin/X11/xterm
dpkg: /usr/bin/X11/xterm not found.
lyonesse$ realpath /usr/bin/X11/xterm
/usr/X11R6/bin/xterm
lyonesse$ dpkg -S /usr/X11R6/bin/xterm
xterm: /usr/X11R6/bin/xterm
However, realpathing the search term doesn't solve the problem:
consider the case where the operator has replaced some standard
directory such as /usr/sbin with a symlink (e.g. to split up /usr over
several partitions due to space constraints, or to identify /usr/sbin
with /usr/bin). Then realpathing the search term would result in
*nothing* in /usr/sbin matching, which is even worse than the current
behaviour.
realpathing filenames as they are written to PACKAGE.list at
install time would solve this, but would break the ability of the
operator to move bits of filesystem around leaving links behind to
keep the standard names working without telling dpkg about it, which
is surely an unreasonable imposition.
realpathing them as they are read from PACKAGE.list in the process of
implementing -S would work better, but dpkg -S is far too slow
already. Even with caching, this would amount to 100,000 or more
lstat() calls on a reasonably package-heavy system.
Anyone got any better ideas?
A solution to the exact example quoted above would be to insist that
PATH entries be the same as the path found in debfiles, (so
e.g. /etc/profile would have /usr/X11R6/bin where it now has
/usr/bin/X11). However this is not a general solution.
ttfn/rjk
Reply to: