Summary: | gnome2 related stuff depends on /var/tmp/portage | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Georgi Georgiev <chutz+bugs.gentoo.org> |
Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED INVALID | ||
Severity: | major | ||
Priority: | High | ||
Version: | 1.4_rc1 | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Georgi Georgiev
2002-10-13 07:58:37 UTC
oh, yes... in the end I DID emerge -b gnome after all :) How did you 'install stuff manually' exactly ? It looks as if the ebuilds never got trough their emerge step (where the builded package gets merged into the live filesystem). I was only doing "emerge -b packagename" until I got tired and "emerge -b gnome"-ed in the end. My computer did an "emerge -b --emptytree gnome" overnight... and it works now... Weird! Not really, apparently you only made packages and didn't merge the files into the system. -b should do it, but for some reason it didnt (?). anyway, closing. If I only made the packages, how did gnome-session end up in my path? And what about the other stuff that gnome-session was executing - nautilus, gnome-settings-daemon and similar. After all, the problems started after I did a rm -rf /var/tmp/portage/* (and then I had to do the workaround with the symlinks), but I now realize that I had forgotten to mention that. It seems that the files were installed where they were supposed to be installed, but the internal paths (maybe hard-coded at compilation or installation) were pointing to the ${D} directory. I am just speculating on the subject... I am not complaining now, just want to have this reported... Well, if it's a reproducable problem and you can give a bit clearer report i would like to have it, but with the way it looks now i can't make much of it. Can be a libtool issue, can be a portage problem.. |