On Tue, Jan 13, 2004 at 04:16:18PM +0300, Dmitry V. Levin wrote:
> Есть набор workaround'ов:
> 
> 1. %undefine __python:
> выключает всю логику поддержки python, в т.ч. и
> /usr/lib/rpm/brp-bytecompile-python
Ну, это оверкилл

> 2. unset RPM_PYTHON в конце %install выключает
> /usr/lib/rpm/brp-bytecompile-python
Done.

> 3. "buildreq -bi" умеет обнаруживать сборочные зависимости на python.
?
alex@pyro ~/RPM/SPECS $ buildreq -bi python-doc-tools.spec 
buildreq: invalid option -- b
buildreq - generates and adds/updates BuildRequires tag in specfiles.
...

А просто buildreq python-doc-tools.spec эту зависимость не ловит.

Ну, в вообще, это не то, на самом деле, чего хотелось бы добиться.

#2 более разумен, как мне кажется. В связи с этим возникает вопрос,
адресованный, скорее, Python Development Team: а не стоит ли вообще удалить
нафиг такую "умолчательную" байткомпиляцию, заменив ее более на
стандартизованные методы сборки питоньих модулей?

Я попробовал, там, вроде, как и в случае с perl'ом, всё замечательно
macro'фицируется (старик Державин корчится от ужаса). Вечером поднимется
Мишин хэшер, я пересоберу всё там, и смогу отдавать со спокойной
совестью на суд общественности. Да, для самых нетерпеливых положил
src.rpm'ы и спеки на http://woland.iae.nsk.su/~alex/python/. Там многое
непричесано, собственно, макросов как таковых и нет почти, но если
какие-то идеи будут востребованы, при проталкивании в upstream их и до
ума можно будет довести.

Пока решил, собирать пакеты в python<version>-<modulename> прежде всего
для удобства этого самого тестирования. В принципе, всю машинерию по 
"два пакета из одного srpm'а" можно убрать, но, мне кажется, различие по
версиям стоит сохранить, хотя бы для тех, кому по каким-то причинам
понадобилось _локально_ держать обе версии питона (н-р, на время
переезда на следующую версию)

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

Кстати, есть ли для питона rpm-скрипты, аналогичные perl.req или
perl.prov? Задача-то более решаема, на первый взгляд, чем для перла...