| Summary: | etc-update from sys-apps/portage-2.0.53_rc7 cannot find module named portage | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Fabian Groffen <grobian> |
| Component: | Unclassified | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED CANTFIX | ||
| Severity: | normal | CC: | grobian, kito |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | PPC | ||
| OS: | OS X | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 115647 | ||
|
Description
Fabian Groffen
2005-11-25 05:07:27 UTC
$ cat /etc/env.d/05portage.envd PYTHONPATH="/usr/lib/portage/pym" You need to env-update. Gentoo's python contains a hack to add in the above path. MacOS was initially supported by hardcoding it throughout portage as well. The above is the happy medium. env-update won't work with the current situation. In the prefix it will. Thanks for the explanation. I'll stick with 2.0.51.22 for now. Prefix? uhm... yeah. Gentoo for OSX currently installs into /usr/bin, where the OS itself places its files too. Because of that, we can't install our own shells for instance. In the prefix we are able to do this, and hence actually source the environment vars without the need to change system provided files (i.e. almost get the same situation the other arches have) Will moving 05portage.envd somewhere else make it work? Would its contents need to be changed? env-update does generate the nice files with all of the settings, AFAIK. The problem is not in there. The generated files (like /etc/profile.env) should be sourced by each shell. Problem of the current (broken) OSX setup is that this is not done. Several considerations apply: - you don't want to touch the global settings, as the OS itself might depend on this, and some of the envs might break it - shell startup files (like /etc/profile) can only be influenced by the installer, which only once installed a bash /etc/profile file (which unfortunately is not that super, and updating is always done through portage, so the file is never updated again) - the current installer only accomodates bash users, tcsh users (old default on OSX) are left out - its just far from optimal at the moment, which is a (legacy) problem on our side. We expect to solve this using a prefix-aware version of portage. So to conclude, I think it's just a pity we can't use the new portage without risking getting some trouble, but this shouldn't be a big problem for long (hopefully). Hmm.. actually, etc-update only uses portageq and portageq still has 'sys.path = ["/usr/lib/portage/pym"]+sys.path' sitting at the top of it. What you are describing doesn't seem possible. Hmm, ok. I added kito which is in general much better in explaining the portage related things. I probably have a wrong understanding of the system as a whole. Pong? ppc-macos legacy problem, IMHO not fixeable. |