от rider@:

$ python
Python 2.6.4 (r264:75706, Dec 21 2009, 02:00:41)
[GCC 4.4.2 20091027 (ALT Linux 4.4.2-alt1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import distutils
>>> from distutils.sysconfig import get_python_lib
>>> get_python_lib();
'/usr/lib/python2.6/site-packages'

get_python_lib() в Pyrex используется в setup.py

Если приведённый rider@ код запустить на x86_64, результат будет:
'/usr/lib64/python2.6/site-packages'

(In reply to comment #0)
> В некоторых ситуациях питон возвращает неверный путь до noarch-каталога.

Может быть, это путь до arch-каталога?

(In reply to comment #1)
> от rider@:
> 
> $ python
> Python 2.6.4 (r264:75706, Dec 21 2009, 02:00:41)
> [GCC 4.4.2 20091027 (ALT Linux 4.4.2-alt1)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import distutils
> >>> from distutils.sysconfig import get_python_lib
> >>> get_python_lib();
> '/usr/lib/python2.6/site-packages'
> 
> get_python_lib() в Pyrex используется в setup.py
(In reply to comment #2)
> Если приведённый rider@ код запустить на x86_64, результат будет:
> '/usr/lib64/python2.6/site-packages'

В реализации get_python_lib() почему-то игнорируется документированный параметр plat_specific.  Исправление, видимо, тривиальное.

(In reply to comment #4)
> В реализации get_python_lib() почему-то игнорируется документированный параметр
> plat_specific.  Исправление, видимо, тривиальное.

С другой стороны, неизвестно, сколько пакетов сломается, если get_python_lib() починить.

Не знаю, как Вам, Дмитрий, а мне ситуация видится так:

лучше всё же починить (сам я это, наверно, быстро сделать не смогу, а у кого можно попросить? Вас? at@?), а что сломается, я готов починить сам (благо, недавно этот пусть уже проходил, но в значительно бОльших масштабах).

В конце концов, бранч 5.1 создан недавно, так что следующее отбранчевание, где окажется новый питон, будет ещё очень нескоро, за это время можно всё это перечинить по нескольку раз.

Поправил так:

From: Eugeny A. Rostovtsev (REAL) real at altlinux.org <real@altlinux.org>
Date: Thu, 14 Jan 2010 21:48:07 +0000 (+0700)
Subject: Fix get_python_lib
X-Git-Tag: 2.6.4-alt3~1
X-Git-Url: http://git.altlinux.org/people/real/packages/python.git?p=python.git;a=commitdiff_plain;h=22265349065b8a586a525c5cc69e4d7dd352ddc9

Fix get_python_lib
---

diff --git a/Python/Lib/distutils/sysconfig.py b/Python/Lib/distutils/sysconfig.py
index 44ae992..05daa02 100644
--- a/Python/Lib/distutils/sysconfig.py
+++ b/Python/Lib/distutils/sysconfig.py
@@ -15,6 +15,7 @@ import os
 import re
 import string
 import sys
+import platform
 
 from distutils.errors import DistutilsPlatformError
 
@@ -115,8 +116,18 @@ def get_python_lib(plat_specific=0, standard_lib=0, prefix=None):
         prefix = plat_specific and EXEC_PREFIX or PREFIX
 
     if os.name == "posix":
-        libpython = os.path.join(prefix,
-                                 "lib", "python" + get_python_version())
+        if plat_specific == 0:
+          libpython = os.path.join(prefix,
+            "lib", "python" + get_python_version())
+        elif plat_specific == 1 and platform.architecture()[0] == "32bit":
+          libpython = os.path.join(prefix,
+            "lib", "python" + get_python_version())
+        elif plat_specific == 1 and platform.architecture()[0] != "32bit":
+          libpython = os.path.join(prefix,
+            "lib64", "python" + get_python_version())
+        else:
+          libpython = os.path.join(prefix,
+            "lib", "python" + get_python_version())
         if standard_lib:
             return libpython
         else:
diff --git a/python-2.6-alt-lib64.patch b/python-2.6-alt-lib64.patch
index b4110b0..08da7c5 100644
--- a/python-2.6-alt-lib64.patch
+++ b/python-2.6-alt-lib64.patch
@@ -17,17 +17,6 @@
          'headers': '$base/include/python/$dist_name',
          'scripts': '$base/bin',
          'data'   : '$base',
---- a/Python/Lib/distutils/sysconfig.py
-+++ b/Python/Lib/distutils/sysconfig.py
-@@ -100,7 +100,7 @@ def get_python_lib(plat_specific=0, standard_lib=0, prefix=None):
- 
-     if os.name == "posix":
-         libpython = os.path.join(prefix,
--                                 "lib", "python" + get_python_version())
-+                                 "lib64", "python" + get_python_version())
-         if standard_lib:
-             return libpython
-         else:
 --- a/Python/Lib/site.py
 +++ b/Python/Lib/site.py
 @@ -265,9 +265,13 @@ def addsitepackages(known_paths):



см. http://git.altlinux.org/people/real/packages/python.git?p=python.git;a=commitdiff;h=22265349065b8a586a525c5cc69e4d7dd352ddc9

(В ответ на комментарий №7)
> Поправил так:
Тогда это не WORKSFORME

Просто это ни на чём ещё не отразилось, собрал парочку arch и многострадальный python-module-Pirex.

Но может вылезти при очередной тестовой пересборке сизифа на каком-то другом пакете, и в нём нужно будет использовать функцию так, как она сама же и описана.

Но раз FIXED, спорить не буду ;)
Пострадавшие переоткроют.

Статус относится к состоянию баги, а не Сизифа.
WORKSFORME - это значит, вы решили ничего не делать, вас и так всё устроило :)
Пересборка покажет? :)

"Пересборка покажет? :)"

Обязательно. Некоторые пакеты, будучи arch, валили свои файлы в %_libexecdir, и в спеках приходилось делать хак: перенос в %_libdir.

Такие пакеты придётся чинить.

(In reply to comment #11)
> "Пересборка покажет? :)"
> 
> Обязательно. Некоторые пакеты, будучи arch, валили свои файлы в %_libexecdir, и
> в спеках приходилось делать хак: перенос в %_libdir.
> 
> Такие пакеты придётся чинить.

Видимо, не один десяток пакетов придётся чинить.  Вот, например, свежепострадавший fetchmailconf:
http://git.altlinux.org/tasks/18725/build/1/x86_64/log

Просьба анонсировать факт починки одного, разлома другого и методы исправления последствий последнего.

"Видимо, не один десяток пакетов придётся чинить.  Вот, например,
свежепострадавший fetchmailconf:
http://git.altlinux.org/tasks/18725/build/1/x86_64/log"

Я предлагаю такое решение. Здесь идёт речь о пакете, часть подпакетов которых на самом деле noarch. Питону это просто так не объяснишь, он если в самом начале не встречает BuildArch: noarch, то дальше уже поздно. Сделал новый макрос: %_python_set_noarch
Его нужно использовать перед любым другим питоньим макросом.

С fetchmailconf получилось совсем просто:
http://git.altlinux.org/people/real/packages/fetchmail.git?p=fetchmail.git;a=commitdiff;h=e3422fb6834f6a340671afe04c628036fac4b095

Предлагаю принять такой вариант. Проверил, собирается.

"Просьба анонсировать факт починки одного, разлома другого и методы исправления
последствий последнего."

Тут разломы могут быть разными, это бы лучше на вики сразу. Но в devel@ пару строк черкну.

#18725 FAILED #2 sisyphus/mike fetchmail.git=6.3.13-alt4

Миш, у тебя нет ключевого фикса, о котором я говорил: в спеке после BuildPreReq: rpm-build-python отсутствует макрос %_python_set_noarch


Потому и FAILED.

(In reply to comment #13)
> С fetchmailconf получилось совсем просто:
> http://git.altlinux.org/people/real/packages/fetchmail.git?p=fetchmail.git;a=commitdiff;h=e3422fb6834f6a340671afe04c628036fac4b095
> Предлагаю принять такой вариант. Проверил, собирается.
Спасибо, смержил и отправил.

> "Просьба анонсировать факт починки одного, разлома другого и методы исправления
> последствий последнего."
> Тут разломы могут быть разными, это бы лучше на вики сразу. Но в devel@ пару
> строк черкну.
Анонсировать стоит и если не вся картинка сразу выяснилась.

(In reply to comment #14)
> #18725 FAILED #2 sisyphus/mike fetchmail.git=6.3.13-alt4
> Миш, у тебя нет ключевого фикса, о котором я говорил: в спеке после
> BuildPreReq: rpm-build-python отсутствует макрос %_python_set_noarch
> Потому и FAILED.
Дело в том, что этот alt4 моложе твоего alt4, на полсуток раньше сделан. :)  Отправил alt5.

PS: посмотри у меня в girar-utils утилитку girar-download, вдруг пригодится:

"Анонсировать стоит и если не вся картинка сразу выяснилась.

А такой анонс уже был: что сборка части пакетов сломается. Фраза слишком общая, согласен, но я не ясновидящий, чтобы видеть всё наперёд. У меня собралось, а то, что кое-что может и не собраться, здесь же, выше по обсуждению говорилось.

Согласен, после исправления get_python_lib нужно было сразу в devel@ написать. Но сейчас все и так уже в курсе:
http://lists.altlinux.org/pipermail/devel/2010-January/179244.html