В некоторых ситуациях питон возвращает неверный путь до noarch-каталога. В качестве примера пострадавшего: http://sisyphus.ru/ru/srpm/Sisyphus/python-module-Pyrex/spec В качестве решения использован костыль: if [ -d %archdir ]; then mv %buildroot%archdir/Pyrex/Compiler/Lexicon.pickle \ %buildroot%python_sitelibdir/Pyrex/Compiler/ fi Но хотелось бы видеть вылеченной причину, а не её следствие.
от 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
