On Wed 10 Mar 2021 at 17:45:48 (-0500), Stefan Monnier wrote: > > I just read this: > > https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ > > It seems as a good idea that merge of /usr. > > I was wondering what would happen if some program used filesystem paths > > as its input data for some processing task. He he, yes, changing status quo > > is not easy > > Here's one source of breakage I encountered a few times because of this > /usr merge (which I generally welcome, BTW): > > dpkg -S =foo > > this (using the Zsh shell) should give me the name of the Debian package > which provides the command `foo`. It works well for most commands, but > it fails for `ifconfig` because `ifconfig` was actually installed in > /sbin/ifconfig (but the /usr merge makes this same /sbin directory > available under the name /usr/sbin so Zsh thinks that `ifconfig` comes > from `/usr/sbin/ifconfig` whereas `dpkg` doesn't have any record of > installing a `/usr/sbin/ifconfig` file).
Sorry, but we're not all familiar with the construct "=foo" as interpreted by zsh, oops, Zsh. Can you elaborate on what dpkg itself is being fed by this command line. I searched man dpkg and man dpkg-query for = but that didn't help. bash: $ dpkg -S ifconfig net-tools: /sbin/ifconfig net-tools: /usr/share/man/de/man8/ifconfig.8.gz net-tools: /usr/share/man/man8/ifconfig.8.gz net-tools: /usr/share/man/pt_BR/man8/ifconfig.8.gz net-tools: /usr/share/man/fr/man8/ifconfig.8.gz $ dpkg -S =ifconfig dpkg-query: no path found matching pattern *=ifconfig* 1 $ Cheers, David.
