The current amd64 stage3 tarball has /usr/local/lib resolve to lib64 but no lib64 directory exists. # tar xjvf stage3-amd64-20120621.tar.bz2 ./usr/local # readlink usr/local/lib lib64 # stat usr/local/lib64 stat: cannot stat `usr/local/lib64': No such file or directory
On my machine, no package owns that directory.
I think that's normal with baselayout-2, isn't it? By contrast, I recall baselayout-1 owning many directories that constitute a normal root filesystem. Presumably, it is now the responsibility of catalyst to ensure that the filesystem structure as it should be, with .keep files preventing portage from doing any damage. Trivial as this issue may be, the point remains that the stage3 should not ship with a broken link and/or missing directories. The structure used to be as follows: /usr/local lib -> lib64 lib32 lib64 I confirmed by checking an older installation ... # find /usr/local -regex '.*lib.*' /usr/local/lib64 /usr/local/lib64/.keep /usr/local/lib /usr/local/lib32 /usr/local/lib32/.keep All of that came from the amd64 stage3 I used at the time (4-5 months ago) and the /usr/local/lib symlink isn't broken.
(In reply to comment #2) > filesystem. Presumably, it is now the responsibility of catalyst to ensure > that the filesystem structure as it should be, with .keep files preventing > portage from doing any damage. No. Catalyst's job is to build a stage3 as a direct reflection of the gentoo-x86 tree. If no ebuild creates some dir, then that dir should not be present on the stage3. With that in mind, there still should not be a broken symlink there.
Hmm, I see what you mean. In principle, a basic /usr/local directory hierarchy ought to exist. In the absence of an ebuild that guarantees its existence, I'm not sure what to suggest.
Contents of the stage: $ ls -l usr/local/ total 8 drwxr-xr-x 2 atlantis atlantis 4096 Jun 21 02:45 bin lrwxrwxrwx 1 atlantis atlantis 5 Jun 21 01:46 lib -> lib64 drwxr-xr-x 2 atlantis atlantis 4096 Jun 21 02:45 sbin But: $ grep /usr/local var/db/pkg/*/*/CONTENTS $ I was able to track the /usr/local tree back to the stage1, but no package lists /usr/local on its CONTENTS file.
I noticed the following the other day when doing a catalyst run: >>> Emerging (1 of 1) sys-apps/baselayout-2.1-r1 for /tmp/stage1root/ >>> Installing (1 of 1) sys-apps/baselayout-2.1-r1 to /tmp/stage1root/ * Messages for package sys-apps/baselayout-2.1-r1 merged to /tmp/stage1root/: * Initializing /tmp/stage1root/lib as a symlink * Initializing /tmp/stage1root/usr/lib as a symlink * Initializing /tmp/stage1root/usr/local/lib as a symlink So this is caused by baselayout @base-system: What do you say?
should be all set now in the tree; thanks for the report! Commit message: Also create the dir that we symlink lib to when SYMLINK_LIB=yes http://sources.gentoo.org/sys-apps/baselayout/baselayout-2.1-r1.ebuild?r1=1.10&r2=1.11 http://sources.gentoo.org/sys-apps/baselayout/baselayout-2.2.ebuild?r1=1.1&r2=1.2
