Re: [devel] Q: Python packaging howto

[Alexey Morozov <alex-altlinux@idisys.iae.nsk.su>]

[-- Attachment #1: Type: text/plain, Size: 5726 bytes --]

On Sat, Feb 21, 2004 at 09:25:33PM +0300, Mikhail Zabaluev wrote:
> Мне не нравится идея, что основное имя (то, которое принимает
> .src.rpm) зависит от ключей сборки. На самом-то деле исходный
> пакет от этого не зависит.
Ну, мне тоже не слишком нравится.

> Может быть, лучше для Name: оставить имя модуля, без всяких python*-,
> а для объявления бинарного пакета предусмотреть макросы? Впрочем,
> это будет не очень удобно, если макрос для объявления бинарного пакета
> не будет автоматически копировать %description основного пакета.
> Я не знаю, можно ли это сделать в rpm.
Вот именно потому, что я тоже не знаю, я и пошел по пути наименьшего
сопротивления.

> Есть ещё такая радикальная идея: бинарный пакет может именоваться и
> по-человечески, именем tarball'а, но предоставлять также имя,
> привязанное к версии ABI python. При этом могут использоваться
> скобочные схемы, например:
> python-abi(%modulename) = %__python_version
> 
> После этого корректное прописывание зависимостей между пакетами
> модулей останется предметом policy.
Хочется не только решить проблему с зависимостями, но и решить проблему
с неединовременным перетеканием всего питоньего хозяйства из одной версии
в другую.

> > Requires: python%__python_package_version-<anotherModule>
> > 
> > Могу оформить все это дело в виде отдельного макроса. Предложения по
> > наименованию принимаются.
> 
> Помимо изложенного выше предложения, есть такой вариант:
> 
> %{python_versioned_name anotherModule}
> 
> а также
> %__python_packagename python%__python_package_version
Ну, ждем, пока остальные выскажутся. Мне, в общем, в данном случае,
практически все равно, куда копать.

> Насколько я понимаю, компиляция после %install необходима только для
> тех скриптов, которые не используют схему установки из distutils
> с опцией --root. Если так, то да, лучше её отключить.
Да.

> По идее, нужно добиться, чтобы RPM_PYTHON была установлена правильно
> во всех случаях.
Ну, я надеюсь, что это так (в смысле, уже установлена)

> Как насчёт %set_python_version по примеру autoconf/automake/libtool?
> Тогда /usr/bin/python из python-common запустит требуемую версию
> или контролируемый альтернативами /usr/bin/python-default.
> 
> Этот же трюк позволит избавиться от --with-pythonXY и таинственного
> макроса setup_python_module: тем, кто захочет зафиксировать версию
> python в своей сборке, достаточно будет вставить
> %set_python_version X.Y в spec
Нет. В спеке НЕ НУЖНО указывать версию питона, потому что в итоге хотелось
добиться возможности сборки модуля под требуемую версию питона МИНИМАЛЬНЫМИ
телодвижениями 

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

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

> Точно так же, нет смысла в общем имени каталога /usr/lib/python
Есть. Для исходников (.py). Они НЕ БУДУТ использоваться напрямую,
а просто для "напосмотреть".

> > %build
> > mkdir -p buildroot
> > 
> > # Unfortunately build and install steps should be done at once
> > # because otherwise .pyo files won't get into INSTALLED_FILES
> > # record
> > 
> > CFLAGS="%optflags" %__python setup.py \
> > 	install --optimize=2 \
> > 		--root=`pwd`/buildroot \
> > 		--record=INSTALLED_FILES
> > %install
> > 
> > cp -pr buildroot %buildroot/
> Не увидел проблем при использовании обычной схемы:
Ну, это место я еще не оптимизировал. К тому же, я игрался на 2.2, там,
помнится, что-то странное происходило в этом месте. Ну и, я пока не понял,
как отнести управляемую байт-компиляцию в %build stage.

> %build
> CFLAGS="$RPM_OPT_FLAGS" python setup.py build
>
> %install
> python setup.py install \
>        --optimize=%python_optlevel \
>        --root=$RPM_BUILD_ROOT \
>        --record=INSTALLED_FILES
Ну и не python, а %__python, все-таки.

> .pyo и .pyc исправно попадают в INSTALLED_FILES.
> Проверял, правда, только на 2.3.
Да, там все нормально.

> P.S. Залил в Sisyphus python-doc версии 2.3.3. Было бы неплохо, если
> бы maintainer Python своевременно обновлял также и этот пакет.
> Там можно прочитать о хорошем способе генерации начального .spec
> для модуля:
> python setup.py bdist_rpm --spec-only
Посмотрите на libAltDist :-)

> Я думаю, об этом стоит написать в HOWTO.
> А может быть, даже подправить шаблон для .spec'а для того, чтобы
> он получался сразу готовым к употреблению.
Уже подправили. Только мне не очень понравилось качество кодирования.


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]