[11:02] <KBar> Hmm, interesting find. The `dpkg --search $(which pwd)` returns an exit status of 1 (dpkg-query: no path found matching pattern /usr/bin/pwd) because the GNU pwd utility is actually installed inside /bin, while which finds it in /usr/bin since /bin is already a symlink to /usr/bin. Both /bin/pwd and /usr/bin/pwd are essentially hard links to the same file pointing to the same inode and `which -a pwd` locates them, as expected. `dpkg
[11:02] <KBar>  --search`, however, still refuses to accept the one in /usr/bin. 
[11:03] <KBar> An intended behavior or potentially a bug?
[11:06] <KBar> This happens with any binary placed in /bin by default. The binaries from the coreutils package are the biggest example.
[11:08] <rbasak> KBar: I think it's expected behaviour as a consequence of the usrmerge and dpkg designs
[11:10] <KBar> I guess `dpkg-query` can't handle hard links. With `sort`, `tail`, etc., which are installed to /usr/bin by default, the exact opposite happens. 
[11:10] <KBar> Or multiple hard links, I should say.
[11:15] <rbasak> I think that it's just not designed to do that. A query goes to its database, without consideration of what's on disk.
[11:15] <rbasak> That might even be a good thing - if the filesystem is corrupt or has been manipulated, then users might expect to see what dpkg thinks should have happened, rather than what is actually there.
[11:18] <KBar> Hmm, I see. Thank you. 
=== teward_ is now known as teward