[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