Am 03.07.2012 18:05, schrieb Dave Reisner: > On Tue, Jul 03, 2012 at 05:48:43PM +0200, Thomas Bächler wrote: >> Am 03.07.2012 17:41, schrieb Dave Reisner: >>> BIG SCARY NOTE: Due to the kmod changes, this will BREAK all module >>> tools for users with their own kernels. If you do not rebuild your >>> kernel after pulling in the new kmod, you're going to have a bad time. >>> See the paste link above for inspiration. >> >> This worries me, a lot. Can't we get a smoother upgrade path? > > Not really. > > We could patch all things using kmod (udev and kmod's tools) to look > in both /usr/lib as well as /lib, but that's ugly and doesn't really do > us any good. > > We could make this rebuild coincide with the glibc rebuild to get rid of > /lib, but you can't install glibc with /lib as a symlink until > /lib/modules doesn't exist. The only way /lib/modules doesn't exist is > if people with custom kernels rebuild them into /usr/lib/modules.
Okay. Why do we want /lib as a symlink to /usr/lib anyway? You could have the directory /lib, only containing the symlinks for ld-linux.so.2 -> /usr/lib/ld-linux.so.2 and ld-linux-x86_64.so.2 -> /usr/lib/ld-linux-x86_64.so.2 (and, of course /lib64/ld-linux-x86_64.so.2 for compatibility). I don't see any advantage in having the symlink /lib -> /usr/lib, except a harder upgrade path where so many things could go wrong.
signature.asc
Description: OpenPGP digital signature
