[Patches] [ python-Patches-629278 ] install lib-dynload .so files mode 555

Sun, 10 Nov 2002 05:08:27 -0800

Patches item #629278, was opened at 2002-10-27 01:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629278&group_id=5470

Category: Distutils and setup.py
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: J. Lewis Muir (jlmuir)
Assigned to: Michael Hudson (mwh)
Summary: install lib-dynload .so files mode 555

Initial Comment:
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.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-11-10 13:08

Message:
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.

----------------------------------------------------------------------

Comment By: J. Lewis Muir (jlmuir)
Date: 2002-11-09 21:06

Message:
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.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-11-08 14:18

Message:
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).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629278&group_id=5470