Esta resposta simples é que os pacotes construídos sem qualquer extensão C / nativa devem acabar sob a lib, qualquer um com extensões nativas acabará na lib64 em sistemas multilib. Quanto ao modo como ele encontra os pacotes está contido em sys.path - isso é de um sistema x86_64 F-11:
>>> import sys
>>> for pth in sys.path: print pth
...
/usr/lib64/python26.zip
/usr/lib64/python2.6
/usr/lib64/python2.6/plat-linux2
/usr/lib64/python2.6/lib-tk
/usr/lib64/python2.6/lib-old
/usr/lib64/python2.6/lib-dynload
/usr/lib64/python2.6/site-packages
/usr/lib64/python2.6/site-packages/Numeric
/usr/lib64/python2.6/site-packages/gst-0.10
/usr/lib64/python2.6/site-packages/gtk-2.0
/usr/lib/python2.6/site-packages
A resposta mais detalhada sobre como os pacotes chegam lá requer um pouco de compreensão sobre como o python funciona em termos de seu próprio layout. O que nos interessa é parte da biblioteca padrão chamada distutils . Este é o cavalo de batalha, note que também existem ferramentas construídas sobre este (setuptools) e um fork chamado distribuir no momento tentando melhorar o empacotamento python.
Existe um patch importante que o fedora se aplica para falar aqui, o que faz tudo isso funcionar:
Este patch é aplicado condicionalmente na especificação do RPM para python em arquiteturas onde a lib lib é lib64:
Se olharmos como esses patches distutam:
diff -up Python-2.6/Lib/distutils/sysconfig.py.lib64 Python-2.6/Lib/distutils/sysconfig.py
--- Python-2.6/Lib/distutils/sysconfig.py.lib64 2008-06-05 08:58:24.000000000 -0400
+++ Python-2.6/Lib/distutils/sysconfig.py 2008-11-24 02:34:04.000000000 -0500
@@ -115,8 +115,12 @@ def get_python_lib(plat_specific=0, stan
prefix = plat_specific and EXEC_PREFIX or PREFIX
if os.name == "posix":
+ if plat_specific or standard_lib:
+ lib = "lib64"
+ else:
+ lib = "lib"
libpython = os.path.join(prefix,
- "lib", "python" + get_python_version())
+ lib, "python" + get_python_version())
if standard_lib:
return libpython
else:
Agora temos uma condição em distutils que agora altera o que distutils.sysconfig.get_python_lib() retorna nos casos em que estamos perguntando sobre pacotes específicos da plataforma ou do sistema. Você pode experimentar isso com várias opções em um interpretador python:
Esta função é usada dentro de distutils - podemos ver na string doc o que ela faz:
Docstring:
Return the directory containing the Python library (standard or
site additions).
If 'plat_specific' is true, return the directory containing
platform-specific modules, i.e. any module from a non-pure-Python
module distribution; otherwise, return the platform-shared library
directory. If 'standard_lib' is true, return the directory
containing standard Python library modules; otherwise, return the
directory for site-specific modules.
If 'prefix' is supplied, use it instead of sys.prefix or
sys.exec_prefix -- i.e., ignore 'plat_specific'.
Portanto, ao usar a construção de um pacote python usando distutils (ou as camadas construídas sobre ele), em algum momento solicitaremos à configuração do sistema onde o local correto para colocar os arquivos, dependendo se é um sistema ou plataforma lib ele vai na lib64 senão vai na lib.
Se você olhar para a documentação do Fedora Python Packaging ou usar a ferramenta fedora rpmdev para criar uma especificação de python esquelético rpmdev-newspec python-foo você verá comentários detalhados de como o fedora define variáveis para a compilação do rpm com base na chamada desta função.