Hi! On Tue, 2017-03-21 at 17:11:58 +0100, Sven Joachim wrote: > Control: forcemerge 134758 -1 > > On 2017-03-21 12:11 +0000, Russell Coker wrote: > > Package: dpkg > > Version: 1.18.23 > > Severity: normal > > > > # dpkg -S /usr/lib/systemd/libsystemd-shared-232.so > > dpkg-query: no path found matching pattern > > /usr/lib/systemd/libsystemd-shared-232.so > > # dpkg -S /lib/systemd/libsystemd-shared-232.so > > systemd: /lib/systemd/libsystemd-shared-232.so > > # ls -l /lib > > lrwxrwxrwx. 1 root root 7 Jan 5 15:04 /lib -> usr/lib > > > > I think that dpkg should know that those 2 filenames are the same and return > > the package systemd in both cases. > > That's a long-standing problem, first reported 15 years ago.
Not really, this case is the reverse, which is searching for the canonical path on the filesystem, but which is not the canonical one on the dpkg db. Solving this from the dpkg side, is non-trivial if not impractical. It would require either scanning the whole filesystem to find aliased pathnames. Or hardcoding the mappings, which would be encoding local policy into dpkg somehow, which it might get out-of-sync with the filesystem contents. Or possibly other ugly things. I covered this in #848622. So, unfortunately, this part, I don't think is fixable. And as I've stated before, while I think the idea behind merged-/usr is fine, the way it's been deployed is not, but this was ignored as a non-issue, so… I think this should be wontfixed, and closed. But if someone can come up with a clean way to handle this, I'm open to suggestions. Thanks, Guillem
