Summary: | dev-lang/python: distutils should support ignoring of distutils.cfg and .pydistutils.cfg | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Joshua Schmidlkofer <menion> |
Component: | [OLD] Development | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | caster, dev-jay |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Joshua Schmidlkofer
2006-10-09 16:55:41 UTC
Here is the shot (uselessly I am certain) of the ebuild ... install command. >>> Compiling source in /var/tmp/portage/java-config-1.3.7/work/java-config-1.3.7 ... running build running build_py creating build creating build/lib creating build/lib/java_config copying ./java_config/__init__.py -> build/lib/java_config copying ./java_config/cfg_parse.py -> build/lib/java_config copying ./java_config/jc_envgen.py -> build/lib/java_config copying ./java_config/jc_exceptions.py -> build/lib/java_config copying ./java_config/jc_iface.py -> build/lib/java_config copying ./java_config/jc_options.py -> build/lib/java_config copying ./java_config/jc_output.py -> build/lib/java_config copying ./java_config/jc_util.py -> build/lib/java_config >>> Source compiled. >>> Test phase [not enabled]: dev-java/java-config-1.3.7 >>> Install java-config-1.3.7 into /var/tmp/portage/java-config-1.3.7/image/ category dev-java !!! SELinux module not found. Please verify that it was installed. running install running build running build_py running install_lib creating /var/tmp/portage/java-config-1.3.7/image/var creating /var/tmp/portage/java-config-1.3.7/image/var/tmp creating /var/tmp/portage/java-config-1.3.7/image/var/tmp/portage creating /var/tmp/portage/java-config-1.3.7/image/var/tmp/portage/java-config-1.3.7 creating /var/tmp/portage/java-config-1.3.7/image/var/tmp/portage/java-config-1.3.7/homedir creating /var/tmp/portage/java-config-1.3.7/image/var/tmp/portage/java-config-1.3.7/homedir/lib creating /var/tmp/portage/java-config-1.3.7/image/var/tmp/portage/java-config-1.3.7/homedir/lib/python2.4 creating /var/tmp/portage/java-config-1.3.7/image/var/tmp/portage/java-config-1.3.7/homedir/lib/python2.4/site-packages creating /var/tmp/portage/java-config-1.3.7/image/var/tmp/portage/java-config-1.3.7/homedir/lib/python2.4/site-packages/java_config copying build/lib/java_config/__init__.py -> /var/tmp/portage/java-config-1.3.7/image/var/tmp/portage/java-config-1.3.7/homedir/lib/python2.4/site-packages/java_config copying build/lib/java_config/cfg_parse.py -> /var/tmp/portage/java-config-1.3.7/image/var/tmp/portage/java-config-1.3.7/homedir/lib/python2.4/site-packages/java_config copying build/lib/java_config/jc_envgen.py -> /var/tmp/portage/java-config-1.3.7/image/var/tmp/portage/java-config-1.3.7/homedir/lib/python2.4/site-packages/java_config copying build/lib/java_config/jc_exceptions.py -> /var/tmp/portage/java-config-1.3.7/image/var/tmp/portage/java-config-1.3.7/homedir/lib/python2.4/site-packages/java_config copying build/lib/java_config/jc_iface.py -> /var/tmp/portage/java-config-1.3.7/image/var/tmp/portage/java-config-1.3.7/homedir/lib/python2.4/site-packages/java_config copying build/lib/java_config/jc_options.py -> /var/tmp/portage/java-config-1.3.7/image/var/tmp/portage/java-config-1.3.7/homedir/lib/python2.4/site-packages/java_config copying build/lib/java_config/jc_output.py -> /var/tmp/portage/java-config-1.3.7/image/var/tmp/portage/java-config-1.3.7/homedir/lib/python2.4/site-packages/java_config copying build/lib/java_config/jc_util.py -> /var/tmp/portage/java-config-1.3.7/image/var/tmp/portage/java-config-1.3.7/homedir/lib/python2.4/site-packages/java_config >>> Completed installing java-config-1.3.7 into /var/tmp/portage/java-config-1.3.7/image/ man: gzipping man page: java-config.1 And - on the same system - a problem with java-config-2+
--- /usr/bin/
--- /var/
--- /var/tmp/
--- /var/tmp/portage/
--- /var/tmp/portage/java-config-2.0.30/
--- /var/tmp/portage/java-config-2.0.30/homedir/
>>> /var/tmp/portage/java-config-2.0.30/homedir/bin/
>>> /var/tmp/portage/java-config-2.0.30/homedir/bin/java-config-2
>>> /var/tmp/portage/java-config-2.0.30/homedir/bin/depend-java-query
>>> /var/tmp/portage/java-config-2.0.30/homedir/bin/run-java-tool
>>> /var/tmp/portage/java-config-2.0.30/homedir/bin/gjl
--- /etc/
--- /etc/java-config-2/
java-config is installed via standard means of python package via distutils eclass, so other packages using it should exhibit the same problem, can you try e.g. www-client/pybugz ? May be also because you forgot to run python-updater or something. And this also looks suspicious: !!! SELinux module not found. Please verify that it was installed. At one time we were going to use SELinux with this system. But... * It's too much work under Gentoo. * It won't give us the control we need over sockets and localhost aliases. GRSec stuff is probably where we will go. I have various python modules installed successfully, but I will retry a couple that I have never used. I will also remove the SELinux python modules. Ok, It is definately a problem in the distutils stuff. Could this be related to setuptools? I have a lot of TurboGears apps on this box. Something is interfering, I will look into the distutils stuff, but do you guys have any advice?
Snip from pybugz:
--- /var/tmp/portage/
--- /var/tmp/portage/pybugz-0.6.11/
--- /var/tmp/portage/pybugz-0.6.11/homedir/
>>> /var/tmp/portage/pybugz-0.6.11/homedir/lib/
>>> /var/tmp/portage/pybugz-0.6.11/homedir/lib/python2.4/
>>> /var/tmp/portage/pybugz-0.6.11/homedir/lib/python2.4/site-packages/
>>> /var/tmp/portage/pybugz-0.6.11/homedir/lib/python2.4/site-packages/bugz.py
>>> /var/tmp/portage/pybugz-0.6.11/homedir/bin/
>>> /var/tmp/portage/pybugz-0.6.11/homedir/bin/bugz
Python people, please advise :) What python is that? I assume "which python" gives you /usr/bin/python which is a symlink to python2.4 which is from a portage ebuild (I've seen this kind of thing happen when someone manually installed python or something like that)? Output of python -c 'from distutils.sysconfig import get_makefile_filename as f;print f()'? Result of grepping for /var/tmp/portage in the file that should have given you? Output of the requested information. (Wow, I learned a thing or two about python today. =) [snip] hosting ~ # which python /usr/bin/python hosting ~ # ls -l /usr/bin/python lrwxrwxrwx 1 root root 9 Feb 13 2006 /usr/bin/python -> python2.4 hosting ~ # python -c 'from distutils.sysconfig import get_makefile_filename as f;print f()' /usr/lib/python2.4/config/Makefile hosting ~ # cat /usr/lib/python2.4/config/Makefile|grep var/tmp RUNSHARED= LD_LIBRARY_PATH=/var/tmp/portage/python-2.4.2/work/Python-2.4.2: hosting ~ # [/snip] try some more things: # equery belongs /usr/lib/python2.4/config/Makefile (requires gentoolkit emerged) # grep ^prefix= /usr/lib/python2.4/config/Makefile (should be "prefix= /usr", I bet you will have "prefix= homedir" or something) In response to the query ==================================================================== hosting / # equery b /usr/lib/python2.4/config/Makefile [ Searching for file(s) /usr/lib/python2.4/config/Makefile in *... ] dev-lang/python-2.4.3-r4 (/usr/lib/python2.4/config/Makefile) hosting / # grep ^prefix= /usr/lib/python2.4/config/Makefile prefix= /usr ==================================================================== OK - the problem The local admin uses a lot of virtual hosting, and has used this to modify the distutils behaviour: http://peak.telecommunity.com/DevCenter/EasyInstall#custom-installation-locations Therefore, the stock python distutils config automatically causes all modules to be installed in the local users python dirs. He created a 'override' config in /root (because with lots of users it's more practical) which is essentially the same as the stock distutils. So = === /usr/lib/python2.4/distutils/distutils.cfg === [install] install_lib = ~/lib/python2.4/site-packages # This next line is optional but often quite useful; it directs EasyInstall # and the distutils to install scripts in the user's "bin" directory. For # Mac OS X framework Python builds, you should use /usr/local/bin instead, # because neither ~/bin nor the default script installation location are on # the system PATH. # install_scripts = ~/bin [easy_install] site_dirs = ~/lib/python2.4/site-packages === /root/.pydistutils.cfg === [install] prefix=/usr install_lib=/usr/lib/python2.4/site-packages install_scripts=/usr/bin [easy_install] site-dirs=/usr/lib/python2.4/site-packages ====================== When HOME is set to /root, distutils behaves as it should - by installing everything in the system dirs. However, if not, then it picks up the default distutils.cfg, and that assumes that you don't have write permission to the system directories. So, Any suggestions? I will work around this for now, but it would be nice to have a more permanent solution. Ick. The first thing that comes to mind is "don't do that then": do not edit files in /usr/lib/python2.4 if you want portage to continue to function properly. Why do you need this change? Is there no way to accomplish it without editing stuff in /usr/lib? Would putting this stuff in $HOME/.pydistutils.cfg work? Ick? This is standard Python setuputils stuff, documented at: http://peak.telecommunity.com/DevCenter/EasyInstall#administrator-installation This is highly desirable for any sort of shared hosting setup as it allows users to maintain their own Python libraries that override the system-wide install. I think the easiest fix would be to check the users home directory for .pydistutils.cfg (or create a default one) prior to trying to use setuputils. An example .pydistutils would be something like: [install] prefix=/usr install_lib=/usr/lib/python2.4/site-packages install_scripts=/usr/bin [easy_install] site-dirs=/usr/lib/python2.4/site-packages Leaving entirely to you guys, seems more apropriate. (In reply to comment #12) > Ick. The first thing that comes to mind is "don't do that then": do not edit > files in /usr/lib/python2.4 if you want portage to continue to function > properly. Why do you need this change? Is there no way to accomplish it without > editing stuff in /usr/lib? Would putting this stuff in $HOME/.pydistutils.cfg > work? > AFAIK, that would work, it's not nessecarily the solution recommended, and I think it would be better to specifically override this, unless That's Bad(tm). Overall, I think that a good sysadmin could accomplish the stock override using skel tools. However, I think that the question should at least be asked about the effects in both cases. After considering this over night, I really believe that Portage should manage these changes. For the moment, portage _always_ installs packages in a system-wide fashion. That being the case, I think a specific .pydistutils.cfg makes more sense then depending on people not /using/ thier systems. I have not read any specific statements about design concepts for portage. I think that portage should continue to function normally, even with an altered distutils.cfg. It make a lot more sense for an /admin/ to change 1 file, rather than 1 file per user. Also, I don't see that this could possibly add significant complexity to portage. I suggest to patch Distutils to ignore distutils.cfg and .pydistutils.cfg when an environmental variable (e.g. PYTHON_IGNORE_SYSTEM_CONFIGURATION_FILES) is set. This variable would be set in make.defaults in base profile (similarly to PYTHONDONTWRITEBYTECODE). *** Bug 329973 has been marked as a duplicate of this bug. *** My inclination here is to add a simple check for the file, and tell the user they're on their own if it exists, rather than hacking up distutils for (bluntly) user idiocy. Comments? "My inclination here is to add a simple check for the file, and tell the user they're on their own if it exists, rather than hacking up distutils for (bluntly) user idiocy. Comments?" My comment: I stopped caring about this bug around 2 years ago and this thread demonstrates clearly why: 1) bugs are due to user "idiocy" (not because users are following *upstream* documentation - you ought to try reading it sometime). 2) we'll get around to explaining that to you in a few years, assuming you haven't pissed off by then. Gentoo has never been, and never will be a distro usable as a server OS precisely because of issues such as this (well, that and suddenly relocating all the files in /etc/httpd now and again during a minor update and then blaming users for not reading volumes of announcements, but that's neither here nor there). What a load of crap. My inclination would be to WONTFIX this, but warning about the existence could work too, I guess. Just feels (a) pretty niche and (b) you should know what you're doing. Okay, since no one responded since last time, I'll close this. |