Seriously? Being able to type dpkg -S $(which cat)
instead of dpkg -S $(which cat|sed 's:^/usr::') is the big user-level pain point? People seem pretty worked up over this, but honestly I'm not understanding why. We already have $PATH which (let's be honest) is an ancient crappy workaround for the original Unix sin of not keeping all the executables in one place. (And analogous wheel-reinventing goo for /lib vs /usr/lib vs /usr/lib/x86_64-linux-gnu, etc.) Given that, moving them around isn't supposed to be a big fuss. Oh, but there are also shebang #!/bin/foo issues and other hard coding. The shebang is already such a mess that people use #!/usr/bin/env foo, just to get foo searched in $PATH. (85 of the 890 scripts in /usr/bin/* on the machine I'm typing this on use a /usr/bin/env trampoline.) Nobody would ever consider having /bin/foo and /usr/bin/foo be different programs, that would be madness. The TC basically concluded that the distinction between /bin and /usr/bin, etc, had totally broken down and there's no advantage to keeping them distinct, plus initrd is the new /bin. (Pretty much the same argument as in the design of plan9.) I'm not seeing much argument against that, except for nostalgia. It seems that dpkg is ground zero for problems that occur during the transition itself, and for the problem of handling the transition gracefully. I for one am enormously impressed with the quality of dpkg: its amazing robustness, the way it's evolved to support hooks and such and really been the cornerstone of the distribution. So I think we should take the dpkg maintainer's concerns seriously. But frankly I don't quite understand them. --Barak Pearlmutter.