Python 3.2a1 in rawhide

David Malcolm dmalcolm at redhat.com
Tue Aug 24 00:25:28 UTC 2010


On Mon, 2010-08-23 at 11:51 +0200, Thomas Spura wrote:
> On Sun, 22 Aug 2010 23:29:38 +0800
> Chen Lei wrote:
> 
> > 2010/8/22 Thomas Spura <tomspur at fedoraproject.org>:
> > > On Sat, 21 Aug 2010 18:48:31 -0400
> > > David Malcolm wrote:
> > > [snip]
> > >>
> > >> So you'll need to update the %files for python3 subpackages,
> > >> listing something like:
> > >>   foo/__pycache__
> > >> to capture the directory and the bytecode files within.
> > >
> > > Unfortunately there is sometimes also a __pycache__ directory in
> > > %{python_sitearch} (etc...) - for example in python3-minimock:
> > >
> > > Checking for unpackaged
> > > file(s): /usr/lib/rpm/check-files /builddir/build/BUILDROOT/python-minimock-1.2.5-5.fc15.noarch
> > > error: Installed (but unpackaged) file(s)
> > > found: /usr/lib/python3.2/site-packages/__pycache__/minimock.cpython-32.pyc /usr/lib/python3.2/site-packages/__pycache__/minimock.cpython-32.pyo
> > >    Installed (but unpackaged) file(s) found:
> > >   /usr/lib/python3.2/site-packages/__pycache__/minimock.cpython-32.pyc
> > >   /usr/lib/python3.2/site-packages/__pycache__/minimock.cpython-32.pyo
> > >
> > > I decided to *NOT* own the __pycache__ directory, because other
> > > python3 packages will have that directory too, so I _believe_ the
> > > main python3 package should own them, isn't it?
> > > python3-minimock currently only owns:
> > > %{python3_sitelib}/__pycache__/minimock*
> > >
> > >        Thomas
> > > --
> > Hi Thomas,
> > 
> > It seems your latest build points purelib to a incorrect place[1], we
> > should install all noarch packages to /usr/lib/python*/site-packages.
> > I also wonder if we can also point stdlib  to /usr/lib/python*, since
> > those files are also arch-independent.
> > 
> > From python docs:
> > - stdlib : root of the standard library
> > - platstdlib: root of platform-specific elements of the standard
> > library
> > - purelib: the site-packages directory for pure python modules
> > - platlib: the site-packages directory for platform-specific modules
> > - include: the include dir
> > - platinclude: the include dir for platform-specific files
> > - scripts: the directory where scripts are added
> > - data: the directory where data file are added
> 
> Your reasoning look ok, but I don't see, why python3 behaves right...
> $ python3 -c "from distutils.sysconfig import get_python_lib;
> print(get_python_lib(1))"
> /usr/lib64/python3.2/site-packages
> $ python3 -c "from distutils.sysconfig import get_python_lib;
> print(get_python_lib())"
> /usr/lib/python3.2/site-packages
> 
> stdlib won't work because of:
> python3 -c "from distutils.sysconfig import get_python_lib;
> print(get_python_lib())" Traceback (most recent call last):
>   File "/usr/lib64/python3.2/sysconfig.py", line 305, in _init_posix
>     _parse_makefile(makefile, vars)
>   File "/usr/lib64/python3.2/sysconfig.py", line 201, in _parse_makefile
>     with open(filename) as f:
> IOError: [Errno 2] No such file or directory:
> '/usr/lib/python3.2/config/Makefile'
> 
> So I'd say we are fine this way (python3 seems to behave right, isn't
> it?)

I'm sorry I didn't get around to looking at this today.  My recollection
is that traditionally the way we've done multilib support is to patch
python so that arch-specific files go below {_libdir}, but
arch-independent files go below /usr/lib.  IIRC I did something like
this for our build of python 2.7 so that it looks in the correct place
for the Makefile.

See
http://pkgs.fedoraproject.org/gitweb/?p=python.git;a=blob;f=python-2.7rc1-lib64.patch;h=9462e829282b3a66ae8306e0290769076aa5d05f;hb=HEAD
(distutils)

and:

http://pkgs.fedoraproject.org/gitweb/?p=python.git;a=blob;f=python-2.7-lib64-sysconfig.patch;h=0cef36192330c023a80b59388920a6ca6b6f8c06;hb=HEAD
(sysconfig).

(These patches are applied only on 64-bit builds).

Note that in the latter I kept "purelib" to be /usr/lib, whereas
"stdlib", "platstdlib", and "platlib" I patched to use %{_libdir}.


Hope this makes sense
Dave



More information about the devel mailing list