So we're working on 2007.0 and we noticed that 2006.1 is kind of in a busticated state as we start to create fresh stages as we're getting our act together for the up coming release. So what's busticated? Well in pure 64 bit ppc64 hippy land we're a twisted lot and for us /lib and /lib64 as well as /usr/lib and /usr/lib64 and so on all need to basically agree on one important thing, they need to be the same damn directory. If they don't agree, it's hatfield and mccoys and lots of shooting ending in a failed stage build for catalyst. Yee-haw! O one more bit of trivia. /lib /usr/lib are the symlinks to /lib64 and so on. We do this as it makes for converting a pure 64 bit system to a multilib system actually a breeze. So what's the problem? Well baselayout 1.12.6 has the following ksym code: ksym() { echo "[[ ! -e ${ROOT}/$2 ]] && { ln -s '$1' '${ROOT}/$2' &> /dev/null || ewarn ' unable to symlink $2 to $1' ; }" \ >> "${D}"/usr/share/baselayout/mklinks.sh } Consider the following: ROOT=/usr/portage/packages/All/tmp emerge --oneshot --nodeps baselayout This will not on ppc64 result in a lib dir point to lib64 in the tmp dir where things are installed, instead we get: drwxr-xr-x 4 root root 4096 Dec 14 21:58 lib drwxr-xr-x 3 root root 4096 Dec 14 21:58 lib64 Them's two dirs ... and them'n'd cause a fight. Not good. So there's a 3 part fix here unless you've got something more civilized: 1) add a ${ROOT} echo "[[ ! -e ${ROOT}/$2 ]] && { ln -s '${ROOT}/$1' '${ROOT}/$2' &> /dev/null || ewarn ' unable to symlink $2 to $1' ; }" \ >> "${D}"/usr/share/baselayout/mklinks.sh 2) pkg_postinst switch the order of the mkdirs.sh and mklinks.sh. Have mklinks.sh go first. 3) pkg_preinst needs to mkdir ${ROOT}/usr/local I can roll this up as a patch if you like, or I can just commit the fix. Thoughts?
Run up a patch please :) Also, you may want to review 1.13.0_alpha as the install system as been radically revamped.
(1) is wrong ... you'd be encoding ${ROOT} in the symlink name which will just give you broken paths (3) doesnt make much sense as /usr/local should be setup for you ... also, we dont make dirs in pkg_* functions anymore as that's the entire point of the mk*.sh files why not just drop "lib" completely in a pure 64bit world
Without (1) the script will be incorrect. $ROOT might be / or /some/path. Consider: /some/path/usr/lib needs to point to /some/path/usr/lib64 just like /usr/lib needs to point to /usr/lib64. Granted "normal" people don't tend to stray from / to /some/path but those in the embedded universe do that sometimes, and while I don't like it, it's not against "the rules". As to (3), it's a chicken and egg situation. You can't make a symlink in a directory that doesn't exist. If you create the directories first then one won't end up with symlinks because ksym doesn't create any symlinks if a directory of the same name already exists. This is the bug. One solution which I've proposed is reverse the order and create the local dir which one needs anyway. While the point of kdir is to populate the script to create the directories, the script does not in fact create all the directories anyway so the step to create /usr/local isn't commiting a sin that hasn't already been done by the package itself.
it is completely against the rules ... there's no need to point out embedded aspects as i write most of that ROOT should never be recorded in ROOT ... nothing should ever know about ROOT after it's done being expanded in the ebuilds, end of story ... so yes, it is against "the rules" if you want symlinks that resolve outside of ROOT, use relative symlinks as for trying to excuse adding in hacks, the purpose is to cleanse them, not continue adding and expanding
So we're all for apple pie and motherhood, that's nice. That doesn't address the bug. Let's be constructive here please. Do you have a counter proposal?
Well, you could go with baselayout-1.13 which lets you choose your own flavor of multi lib as quite frankly with everyone having their own view of lib being a link to lib64 or lib64 being a link to lib or in the case of sparc64/fbsd just having lib as the UL is also pure64 AND with catalyst getting in on the act of affecting the directories baselayout can/cannot create (ie we're not allowed to create /dev, /proc, etc). How does this work? The answer is we don't actual do anything multi lib except for setting LDPATH in /etc/env.d You want symlinks? Set them up yourself.
what are you talking about ? i am being constructive; i'm telling you what wont work and why it wont work and in fact i even suggested some other ideas which you did not comment on where do you "set them up yourself" ? catalyst should not be entering the picture here
what profile are you testing with ? cause things work just fine over here: # ROOT=/dev/shm/ emerge baselayout -q --nodeps >>> Emerging (1 of 1) sys-apps/baselayout-1.12.8-r1 to /dev/shm/ ... # ls -ld /dev/shm/{,usr/,usr/local/}lib* lrwxrwxrwx 1 root root 5 Dec 30 02:06 /dev/shm/lib -> lib64 drwxr-xr-x 3 root root 0 Dec 30 02:06 /dev/shm/lib64 lrwxrwxrwx 1 root root 5 Dec 30 02:06 /dev/shm/usr/lib -> lib64 drwxr-xr-x 3 root root 0 Dec 30 02:06 /dev/shm/usr/lib64 lrwxrwxrwx 1 root root 5 Dec 30 02:06 /dev/shm/usr/local/lib -> lib64 drwxr-xr-x 2 root root 0 Dec 30 02:06 /dev/shm/usr/local/lib64 # emerge --info Portage 2.1.2_pre1 (default-linux/ppc/2005.1/ppc64/64bit-userland, gcc-4.1.1, glibc-2.5-r0, 2.6.19.1 ppc64)
ranger reported it with catalyst and default-linux/ppc/2006.1/ppc64/64bit-userland It'll show up once you hit stage2. For systems that are already setup from a "good" stage3 you'll never see it. Anyway if the goal is to be no symlink. It's either all /lib or /lib64. 1) /lib64 : Pro: glibc's view on the world Con: Risk for random packages that presume /lib so going this route means being ready to potentially fix the world 2) /lib : Con: glibc would need to get fixed (somewhere in the loader it's hardcoded) Pro: Everything else "just works: Open questions; What's the linux file standard say? What's AMD64 doing? While ppc64 is a bit different than amd64 in some respects, seems like the path that amd64 has blazed for 64 bit should be the one ppc64 should follow (and originally what I was doing back in the day when brad was running the show)
so I went ahead and did a little work to setup for and try out a complete system going down the /lib64 case with no /lib. The results are interesting as they point out just for a stage1 what the state of affairs are just for small set of packages and assumptions about /lib are. Important : Symlinks are off and this uses the current stable baselayout which is the subject of this bug. /lib was still created with the contents being: timberdoodle lib # ls cpp dev-state rcscripts udev-state cpp makes sense as that involves unix heritage going back to the 80s. The rest are obviously packages that must have /lib hardcoded. /lib64 is setup correctly, runs and is sane. /usr/lib64 again is created, setup, works and is sane. /usr/lib is a symlink pointing to /usr/lib64 even tho symlinks are turned off. All in all, not what I'd call a great showing for a stage1 with a small set of packages. If the base-system team really recommend that route we can certainly do this, but there will be a bit of a risk as to the creation of a bugstorm to hunt down all packages which have hardcoded /lib or /usr/lib install paths. Comments?
fixed
stick a fork in it
