For a decade or so I've been running a stable system, where /lib64 was a real directory, and /lib was a symbolic link pointing to /lib64. My profile was: hardened/linux/amd64/no-multilib Then I read: https://www.gentoo.org/support/news-items/2017-11-30-new-17-profiles.html I've decided to update and follow these steps. I've selected: default/linux/amd64/17.1/no-multilib/hardened as my new profile. However, the 'emerge -e @world' step broke my system. After investigation, it turns out it was the rebuild of sys-apps/baselayout-2.4.1-r2 that screwed things. The first 2 steps this ebuild did (bricked my library directory layout, and hence rendered the system unusable): Converting /lib from a symlink to a dir Converting /usr/lib from a symlink to a dir The /lib afterwards was just an empty directory - clearly wrong. This comes from line 87 of baselayout-2.4.1-r2.ebuild. With lib being just an empty directory, the system couldn't run any dynamically linked commands, I couldn't even log on. I found a work-around, more less like this: Access / from a live cd. rmdir /lib mv /lib64 /lib sln /lib /lib64 Repeat also for /usr/lib*. This turns things around: /lib becomes the actual directory, and /lib64 is a symlink to it. Now recompiling baselayout went OK and the system works. The only inconvenience is that on every emerge, I get the warning: * One or more symlinks to directories have been preserved in order to * ensure that files installed via these symlinks remain accessible. This * indicates that the mentioned symlink(s) may be obsolete remnants of an * old install, and it may be appropriate to replace a given symlink with * the directory that it points to. * * /usr/lib64 So I believe my original arrangement was correct. I don't quite see why in the new profile baselayout wants to turn things around (even if it could do it without bricking the system). I also recommend changing 'ln -s' to 'sln' in the ebuild. sln is more robust as it's statically linked, works even when library directories are screwed.
Read all the fucking news: https://www.gentoo.org/support/news-items/2017-12-26-experimental-amd64-17-1-profiles.html This is an experimental profile: default/linux/amd64/17.1 The only diffenence to default/linux/amd64/17.0 is: SYMLINK_LIB="no" using multilib I don't know yet what about using no-multilib in your case. Using the multilib works fine when executing the tool and the steps mentioned in the above html
For people using the multilib the second and last difference is Profile default/linux/amd64/17.0 : LIBDIR_x86="lib32" Profile default/linux/amd64/17.1 : LIBDIR_x86="lib" which is why I don't know how the no-multilib case is handled.
Perhaps we could make a feature request out of this bug: if a profile "default/linux/amd64/17.1" is used then perhaps portage could look if exists as symlinks /lib /usr/lib then request 1. the tool app-portage/unsymlink-lib should be installed 2. this NEWS should be read: https://www.gentoo.org/support/news-items/2017-12-26-experimental-amd64-17-1-profiles.html This way many Gentoo users running into the pre-mature death could be saved
You're answer, however rude, is still useful, because you pointed me to a hidden news item. Perhaps if you want the users to read this news item, you should not hide it from users. This news item would save me days of work, yet it was never shown to me. As I wrote, my original profile was hardened/linux/amd64/no-multilib and the item isn't shown there! I had this profile for years and have never seen any news about its obsoletion or removal. So problem #1 is news hidden from most relevant users. Actually, even after I switched to 17.1, the news item was still hidden from me. If anybody should read this, it should be people who switched to it, so they are for sure informed what they switch to. Problem #2 is 'experimental' profiles added to stable-system profile list. Huge mistake. So I saw the news about new 17.0 profiles, then saw 17.1 profiles added, my only sound conclusion was that there was some issues with 17.0 and 17.1 were added to fix it. Never in my wildest dreams would I imagine that somebody pushes experimental stuff on all stable users. There should be some solution so only people having unstable baselayout or unstable portage can see these profiles. I consider extending the audience of your news item to hardened/linux/amd64/no-multilib as a satisfactory solution, after which AFAIAC you can close this bug.
"Read the fucking NEWS" rudeness greatly was directed against myself, because I did make the same mistake days before you not reading. So, please, make some kind of feature request out of the bug !!!
I have removed the 17.1 profiles from the eselect profile list. This may be reverted once eselect has been modified to display the profile status.
