Re: Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)
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.
Reply to: