Created attachment 436560 [details] `emerge --info' output Hello. I maintain a stage4 chroot that functions as a build machine for several binpkg client machines. I recently rebuilt -e @world in that chroot to switch to compressed debug symbols (i.e. FEATURES="compressdebug splitdebug") and then updated the binpkg client machines. Near the end of the merge, baselayout failed to install, complaining about /lib not being a symlink to /lib64 despite my system profile requiring it. Closer inspection revealed that was actually the case: /lib was a directory in its own right. I ran the following to correct the problem: # rsync -vuhaxHAX /lib/ /lib64/ # rm -rf /lib/ # ln -s lib64 /lib (The -u switch ensures I don't overwrite newer files with older ones). The output of rsync showed that only /lib/netifrc/ was transferred, and inspecting the .tbz2 for netifrc showed that it does indeed install files into /lib/. This is how I'm certain that netifrc is to blame... but I could still be wrong. It is important to note that of the several binpkg client machines in this setup, only one was affected by this problem, but that may be due to the differing order of package installation or something else. I don't have enough information to reproduce the problem. You may want to update Portage to not replace a /lib symlink with a /lib directory if the profile says that it should be a symlink.
There are in fact many ebuilds that install things in sub-directories of /lib. For example, any ebuild that installs udev rules will put them in /lib/udev/rules.d. It is highly unlikely that netifrc had anything to do with he symlink being removed; rather, it was probably installed after something else had removed the symlink. If you can come up with a way to reproduce the /lib symlink being removed by your package manager, please re-open this. Otherwise, there is simply no way to know how that could have happened.
