Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 158186 - sym foo, dir foo and ppc64 fun
Summary: sym foo, dir foo and ppc64 fun
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] baselayout (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo's Team for Core System packages
Depends on:
Reported: 2006-12-14 20:25 UTC by Tom Gall (RETIRED)
Modified: 2007-01-06 20:04 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Tom Gall (RETIRED) gentoo-dev 2006-12-14 20:25:58 UTC
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.


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/

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/

2) pkg_postinst

switch the order of the and Have 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?
Comment 1 Roy Marples (RETIRED) gentoo-dev 2006-12-15 04:34:30 UTC
Run up a patch please :)

Also, you may want to review 1.13.0_alpha as the install system as been radically revamped.
Comment 2 SpanKY gentoo-dev 2006-12-15 22:00:40 UTC
(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
Comment 3 Tom Gall (RETIRED) gentoo-dev 2006-12-17 17:50:11 UTC
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.

Comment 4 SpanKY gentoo-dev 2006-12-17 22:22:51 UTC
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
Comment 5 Tom Gall (RETIRED) gentoo-dev 2006-12-18 10:21:47 UTC
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? 
Comment 6 Roy Marples (RETIRED) gentoo-dev 2006-12-18 11:32:28 UTC
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.
Comment 7 SpanKY gentoo-dev 2006-12-18 23:21:06 UTC
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
Comment 8 SpanKY gentoo-dev 2006-12-29 23:08:33 UTC
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, ppc64)
Comment 9 Tom Gall (RETIRED) gentoo-dev 2007-01-02 20:34:16 UTC
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)

Comment 10 Tom Gall (RETIRED) gentoo-dev 2007-01-03 13:43:14 UTC
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.


Comment 11 Tom Gall (RETIRED) gentoo-dev 2007-01-06 20:04:06 UTC
Comment 12 Tom Gall (RETIRED) gentoo-dev 2007-01-06 20:04:22 UTC
stick a fork in it