| 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:02 |
| KBar | An intended behavior or potentially a bug? | 11:03 |
| KBar | This happens with any binary placed in /bin by default. The binaries from the coreutils package are the biggest example. | 11:06 |
| rbasak | KBar: I think it's expected behaviour as a consequence of the usrmerge and dpkg designs | 11:08 |
| 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:10 |
| 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:15 |
| KBar | Hmm, I see. Thank you. | 11:18 |
| === teward_ is now known as teward | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!