[Distutils] bdist_rpm and bdist on x86-64

Mihai Ibanescu misa at redhat.com
Tue Apr 19 15:51:37 CEST 2005


On Tue, Apr 19, 2005 at 03:00:49PM +0200, M.-A. Lemburg wrote:
> Jeremy Sanders wrote:
> > On Mon, 18 Apr 2005, M.-A. Lemburg wrote:
> > 
> >> Why not os.exists() ?
> 
> s/os.exists/os.path.exists
> 
> > Probably better :-)
> > 
> >> Wouldn't checking for the lib file in either lib64
> >> or lib be more reliable ?
> > 
> > That might be better. I don't know whether it's possible that more than
> > one python is installed (one in /lib and one in /lib64).
> 
> That would certainly be possible.
> 
> >> Hmm, this is not entirely correct, e.g. Suse 9.2 puts
> >> the site-packages directory and all the other .py files
> >> into /usr/lib64 as well - not only the platforma dependent
> >> files.
> >>
> >> Not sure what other AMD64 distros do... but I have a feeling
> >> the /lib/ should *always* be replaced by unix_platlib.
> > 
> > 
> > It looks like RedHat/Fedora patch their package to only put the platform
> > specific files in /lib64 (that's how I made my patch).
> > 
> > Perhaps this isn't a good idea to do then :-(  I wonder whether it would
> > be possible for distribution to set these values somewhere. Couldn't
> > python have a sys function to return its Makefile?

Fedora does it this way because of .noarch.rpm packages. Pure python
libraries should run just fine both on x86 and x86_64, and since it's /usr/lib
on x86, x86_64 has to know about /usr/lib too (which is sort of confusing).

I believe you can get away without patching anything, if you do:

from distutils import sysconfig
print sysconfig.get_python_lib()

to which you either pass plat_specific = 0 or 1. This will properly parse the
right Makefile (which is probably what you ended up doing).

Misa


More information about the Distutils-SIG mailing list