Issue629278
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2002-10-27 00:03 by jlmuir, last changed 2022-04-10 16:05 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
python-2.2.2-setup.py.diff | jlmuir, 2002-10-27 00:03 | patch against python-2.2.2 release | ||
mwh-patch-1 | mwh, 2002-11-08 14:18 | mwh's first patch | ||
setup.py-2.2.2-jlmuir-v2.diff | jlmuir, 2002-11-09 21:05 | jlmuir's second patch against 2.2.2 release | ||
setup.py-HEAD-jlmuir-v2.diff | jlmuir, 2002-11-09 21:06 | jlmuir's second patch against HEAD |
Messages (8) | |||
---|---|---|---|
msg41453 - (view) | Author: J. Lewis Muir (jlmuir) | Date: 2002-10-27 00:03 | |
This is a patch to the setup.py file to set the permissions of the installed shared libraries to have mode 555 (r xr xr x). This fixes bug #549338 "lib-dynload/*.so permissions wrong" and a duplicate bug #583206 "lib-dynload/*.so wrong permissions". The problem was that the shared libraries are installed by simply copying the tree of built shared libraries from the build directory to the installation location. This means that the permissions of the installed shared library files will be whatever the permissions were on these files in the build directory. The permissions are never set. If the shared libraries do not have the execute bit set, then on some platforms (Linux, in my case), python will be broken. For example, if one tries to import the time module, python will raise an ImportError saying "No module named time". To fix this, I've added a class PyBuildInstallLib(install_lib) which does exactly what install_lib does by invoking the super implementation of the install method, but then sets the permissions correctly for the installed shared library files. In the setup call in the main function, I pass this PyBuildInstallLib class in the cmdclass dictionary as the class that should be used for the 'install_lib' command. Another approach would be to instead modify the Makefile to set the correct file modes of the installed shared library files in the 'sharedinstall' target right after running '... setup.py install ...'. I didn't do this because it seemed other file modes were being set by other commands in distutils so it seemed appropriate to do the same. Attached is a patch against the 2.2.2 release. This I have tested on my machine (x86, Mandrake 8.0 + updates, Linux 2.4.18). I've also looked at what's in CVS and my changes can be trivially made to the setup.py that's in CVS as of Sat 2002-10-26 5pm CDT. |
|||
msg41454 - (view) | Author: Michael Hudson (mwh) | Date: 2002-11-08 14:18 | |
Logged In: YES user_id=6656 Thanks for looking at this! This is a bit of a hack, but ne'er mind; I've been trying to think of a clean way of doing this for a while. I'd prefer to use sysconfig.get_config_vars("SO") than your hardcoded list of possible DSO extensions. Can you try the attached? (err, it's against HEAD but should apply to 2.2.2 with little difficulty). |
|||
msg41455 - (view) | Author: J. Lewis Muir (jlmuir) | Date: 2002-11-09 21:06 | |
Logged In: YES user_id=527708 I didn't know about the sysconfig thing; I like that much better. I tried your patch against the 2.2.2 release and it works fine. After revisiting this, I had a few more ideas for improvement. I think it would be even better if the access modes for all installed files and directories were actually deterministic whereas with our existing changes, only the modes of the shared library files are guaranteed to be set correctly. We are still left with all files (other than the shared libraries) and all directories having modes that are based upon whatever the modes were in the build tree that gets copied into the install dir. I've attached two patches: setup.py-2.2.2-jlmuir-v2.diff (against the 2.2.2 release) setup.py-HEAD-jlmuir-v2.diff (against HEAD) These patches incorporate your changes plus my new changes to make all installed file and directory modes get set correctly. I've tested the patches with their corresponding 2.2.2 release and HEAD. My new changes cause the mode of all installed files to be set to 644 unless they are shared libraries in which case they will get mode 755 and all directories will get mode 755. Note that I've tweaked the mode of shared libraries to 755 instead of 555. I only did this because it seemed more standard. However, the INSTALL_SHARED variable defined in Makefile uses mode 555 (so if you'd rather stick w/ 555, I'm fine with that). In the HEAD patch, I changed from using self.announce to log.info because self.annouce wasn't printing anything to stdout and it seems that other commands are now using log.info (e.g. clean.py). There is one issue that might not be worth worrying about, but I'll state it anyway. My changes will set the mode of the install dir and all descendant dirs in the tree. If the destination install dir already exists or has other dirs in it that already exist, the mode will be set for all of those dirs even if they were not part of the directory tree copied from the build dir. In practice, I don't think this will be an issue, but who knows. Alternatively, I could have extracted directory names from the list of installed files but if a directory was created that had no files in it, that directory would not get discovered and hence its mode would not get set. |
|||
msg41456 - (view) | Author: Michael Hudson (mwh) | Date: 2002-11-10 13:08 | |
Logged In: YES user_id=6656 This is looking promising! Wrt 0555 vs 0755: *I* don't care, but I may not be a sufficiently hairy-chested unix admin to see why one is preferable over the other. Wrt logging: I haven't tried your patch yet, but will note that there's been a general effort to get distutils to shut up in 2.3 - so if the announcements don't appear unless you run "python setup.py -v", that's probably a good thing. I have faint concerns that chmod-ing the directories might run afoul of permissions in some settings. Perhaps I should go see what install_lib.install actually returns, but given that we've never had a problem report about directories it might be easier to drop that bit. Now, if your feeling *really* ambitious, it would be nice to have this fix as part of distutils proper, not some band-aid fix just for Python's setup.py... but don't feel obliged to look at this. |
|||
msg41457 - (view) | Author: J. Lewis Muir (jlmuir) | Date: 2002-11-10 20:21 | |
Logged In: YES user_id=527708 WRT logging: Argh! In that case, it may need to be changed back. :-) I just want it to be consistent w/ the rest of the install process. Right now the "copying SOURCE -> DESTINATION" messages print to stdout as setup.py is invoked from the sharedinstall Makefile target, but the "changing mode of FILENAME to MODE" messages that this patch adds do not print to stdout when using the announce method. WRT directory modes: If at all possible, I'd like to keep this in. In the testing I did, the shared lib directory (in the build directory) that gets copied has a mode controlled by the umask of the user compiling python. So if I set my umask to 077 and compile python, then the shared lib directory in the build directory will have mode 700 and will have the same mode when it gets copied into the install location. I think it is cleaner to explicitly set all file and directory modes instead of depending on the umask setting of the user. WRT putting this in distutils: I'm possibly willing to do it; I'd have to look into it. I was intentionally avoiding making any changes to distutils proper as I didn't want to break anyone else who may be using install_lib and I don't know what the policies are WRT API changes (e.g. at what version is it ok to break backward compatibility, etc). |
|||
msg41458 - (view) | Author: Michael Hudson (mwh) | Date: 2002-12-05 21:16 | |
Logged In: YES user_id=6656 Any progress here? Are you happy enough with the patch as attached? (I've left this too long and slightly forgotten all the issues :-() |
|||
msg41459 - (view) | Author: J. Lewis Muir (jlmuir) | Date: 2002-12-06 21:28 | |
Logged In: YES user_id=527708 Yeah, I'm happy enough w/ the patch as attached. BTW, I looked into the logging again and I think that the use of 'log.info' for logging is ok for now because it produces results that are consistent w/ the rest of the install process. It would seem that to support the '-v' verbose option to 'setup.py', the logging level threshold of the global log in the 'log' module would need to be set correctly. This could be done by calling 'log.set_threshold(log.WARN)' as the default logging threshold for the install process. If the '-v' option was given to 'setup.py', then 'log.set_threshold(log.INFO)' would instead be called. With this, the calls to 'log.info' in our patch should print something only if the '-v' option was specified for the 'setup.py' invocation. |
|||
msg41460 - (view) | Author: Michael Hudson (mwh) | Date: 2002-12-17 16:48 | |
Logged In: YES user_id=6656 OK, checked in as setup.py revision 1.127 No more patches assigned to me! Yippee! |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:05:47 | admin | set | github: 37373 |
2002-10-27 00:03:42 | jlmuir | create |