Hi. Recently I set up a system using the stage3-amd64-hardened+multilib-2006.0.tar.bz2 tarball available under the experimental/ sub-directory of the OSU mirror and have been running into several issues here and there. It wasn't until I came across bug 125032 that I discovered that "/usr/lib" was not a symlink to "lib64", even though the amd64 hardened profiles assert SYMLINK_LIB="yes". I then proceeded to check the contents of the following stageballs: (1) stage3-amd64-hardened+multilib-2006.0.tar.bz2 (2) stage3-amd64-hardened-non-multilib-2006.0.tar.bz2 (3) stage3-amd64-2006.0.tar.bz2 Only (3) had the symlink defined correctly within the tarball rather than existing as an independent directory. The question is why? There are some rather thorny issues that surround this particular topic - for example see some of the nefarious goings on described in bug 109922. In my case, the absence of this symlink affected webapp-config (bug 125032) and mysql (bug 111073) and I have no doubt that other things in portage would be adversely affected too. Although (a) it is nice to determine/fix bugs in other packages (b) I can easily fix things up locally ... it's not nice that the stageball is shipped in such a fashion that things in the tree currently marked stable just don't work. To summarise: is there any reason for this inconsistency and is it possible for something to be done about it?
If you need me to commit something to the profile I'm happy to. But tracking down the problem here will require somebody that owns an amd64 todo some testing on his/her own.
I should be able to do as much testing as required provided that it remains within the context of a chroot. Anything beyond that would be up to the owner in this case (ragnaroc). In any case, I'll do whatever I can to investigate the issue further.
I found the exact same thing - I had both /usr/lib and /usr/lib64! It got worse as I emerged packages. Some of the files went into /usr/lib and others of them went into /usr/lib64 (like foomatic for some reason). I even had some applications value to emerge with sandbox violations. What I did to get things to work right was copy all the files (and subdirs) of /usr/lib to /usr/lib64 (there were only a few collisions), removed /usr/lib and created the symlink. After that everything worked just dandy! The really funny thing is the /lib and /lib64 were ok. It was just /usr/lib that was screwed up.
BTW, I should mention I built both types of systems - hardened and normal - and the condition exists on both of them.
*** Bug 132979 has been marked as a duplicate of this bug. ***
i just got bit by this problem trying to install rubygems. ruby went into /usr/lib64 and rubygems went into /lib. things blew up after that. we should not have users installing with broken stage files only to discover weeks later that their machines have all sorts of odd problems. lets save everyone's time and remove the broken stage files from the mirrors ASAP.
amd64 team can't do anything about this, entirely hardened's domain, thus removing us from CC
*** Bug 176894 has been marked as a duplicate of this bug. ***
*** Bug 176943 has been marked as a duplicate of this bug. ***
hrmm this is an old bug. agaffney fixed this bug some time ago with an -r1 release.
