Not every user cares about having a statically linked set of core packages. For example, Bash links statically with Ncurses. PAM links with its own berkdb. Etc. Before, this was important, as to insure that the user could still login if the files in the /usr tree were messed up. And also, if any base libraries had problems, then the core utilities could still be used. However, with livecd's everywhere, this because less important, and some people would prefer to have less bloat. Ideally, there would even be a nostatic use flag that disables static libraries entirely. But this is a different issue. Reproducible: Always Steps to Reproduce:
IMHO, not having to depend on livecds is better, as being unable to login if /usr can't be mounted (for example needs to be fsck'd) is quite annoying and needs you to have hardware access. So i don't see the need for something like that.
Right. Which is why this is a use flag. And secondly, /lib isn't always broken. Actually, it hasn't been broken ever since I started on Linux over a year ago. Statically compiling for instance, Bash, is only useful for when /lib/libncurses.version-numbers is messed up. And how many times has that file been messed up on your computer?
i dont think added complexity is worth it we make sure files in /lib /bin /sbin are kept sane and they dont depend on files in /usr if your / becomes screwed up, sash exists as a static shell with a lot of built in utilities to recover your system also, having a static bash would break sandbox, which is bad ;) aaaalso, we force bash to pull in libncurses.a so that ABI changes in ncurses does not affect bash