On Fri, Feb 20, 2004 at 03:00:41PM +0300, Mikhail Zabaluev wrote:
> Хотелось бы узнать, желательно в виде howto или примера spec'а, как
> сложился/складывается официально одобренный способ сборки модулей
> для python. На меня повесили сборку PyXML для python 2.3, хотелось
> бы это сделать сразу правильно.
В аттачменте файл python, который, по-хорошему, идет в python-common
и пример спек файла. Собирать при помощи

rpmbuild -ba pyserial.spec

На выходе будет python-pyserial-*.rpm, причем, бинарные rpm привязаны к
текущей (вероятно, 2.3) версии python. Если нужна сборка под какой-либо
конкретный питон, то

rpmbuild -ba pyserial.spec --with pythonXY

на выходе будут получаться

pythonXY-pyserial...rpm

в данный момент, в качестве XY может использоваться 22, 23 и (задел на
будущее) 24. К сожалению, я не придумал, как можно сделать это место
полностью универсальным.

Зависимости на пакеты с другими модулями python надо прописывать как

Requires: python%__python_package_version-<anotherModule>

Могу оформить все это дело в виде отдельного макроса. Предложения по
наименованию принимаются.

Да, попробуйте все это погонять в разных установочных средах, возможно,
в макросах есть ошибки и/или недочеты.

> Мои беглые мысли по поводу отдельных идей, высказанных в дискуссии
> (кстати, с архивами в http://www.altlinux.ru/pipermail/devel/
> какая-то беда: части сообщений я там не вижу). Отбрасывать .pyc
> нежелательно, поскольку это то, что интерпретатор использует
> по умолчанию без ключа оптимизации. Я не уверен, скажем, что отладка
> работает на .pyo
Данные макросы никак не затрагивают эту область. То есть, метод
сборки и упаковки определяется исключительно пэкеджером. Единственное
условие - делать в конце %install unset RPM_PYTHON, чтобы исключить
скорее всего нежелательную (повторную) байт-компиляцию. Хотя, конечно,
сейчас этот самый RPM_PYTHON, по-хорошему, будет указывать именно на ту
версию питона, для которой собирается пакет (даже если идет сборка по
умолчанию)

У меня есть идея оформить стандартные действия при инсталляции макросами,
аналогичными %perl_vendor_build/%perl_vendor_install, которые бы покрывали
основные нужды сборщиков (при использовании distutils). Вероятно, сегодня
ближе к вечеру это будет сделано. Скорее всего, по умолчанию будут
паковаться только .pyo, но, надеюсь :-), будет возможность, во-первых,
собрать [отдельный] пакет с .py, а, во-вторых, переключиться на
использование .pyc.

> Вообще вся затея обеспечить постепенную миграцию может принести
> больше проблем, чем разовая смена всех модулей в день Д с
> предварительной подготовкой, возложенной на packager'ов.
Я тут уже высказывал сомнения в практической реальности такого "Часа Ч".
Вкратце: не все питоньи модули можно пересобрать в тот же момент, когда
появляется новая версия питона. Пример - Zope, который его создателям и
Андрею понадобилось патчить для обеспечения функционирования под
python2.3. Как следствие, "Час Ч" растягивается по времени месяца на
полтора-два. А вот, например, мне ждать Зоупа нет никакого смысла,
поскольку я его не использую, а Твистед, кажется, едет на 2.3 вполне прилично.
Ну и так далее. Конечно, в "дистрибутив" крайне желательно запихивать
только один питон с полным набором модулей к нему.

Дополнительные замечания по поводу сборки:

в данной схеме есть один, как мне кажется, недочет. Если некто
пересобирает модуль вида pythonXY-pyModule-K.L.M-altN.src.rpm, не
указывая --with pythonXY, то на выходе он получает модуль, привязанный к
ТЕКУЩЕЙ версии питона, а не к версии X.Y. Имена и зависимости пакетов
изменяются соответственно (то есть, будет
python-pyModule-K.L.M-altN.i586.rpm, зависящий от python, запускаемого
как /usr/bin/python).

В принципе, я, похоже, уже знаю, как обойти эту проблему (если это проблема),
правда, блин, хак будет тот еще (хоть и не требующий изменения ни в спеке,
ни в rpm). Такая возможность интересна?