[devel] Q: Python packaging howto

[Mikhail Zabaluev]

Hello Alexey,

On Sat, Feb 21, 2004 at 05:37:26PM +0600, Alexey Morozov wrote:
>
> В аттачменте файл python, который, по-хорошему, идет в python-common
> и пример спек файла. Собирать при помощи
> 
> rpmbuild -ba pyserial.spec
> 
> На выходе будет python-pyserial-*.rpm, причем, бинарные rpm привязаны к
> текущей (вероятно, 2.3) версии python. Если нужна сборка под какой-либо
> конкретный питон, то
> 
> rpmbuild -ba pyserial.spec --with pythonXY
> 
> на выходе будут получаться
> 
> pythonXY-pyserial...rpm

Мне не нравится идея, что основное имя (то, которое принимает
.src.rpm) зависит от ключей сборки. На самом-то деле исходный
пакет от этого не зависит.

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

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

После этого корректное прописывание зависимостей между пакетами
модулей останется предметом policy.

> в данный момент, в качестве XY может использоваться 22, 23 и (задел на
> будущее) 24. К сожалению, я не придумал, как можно сделать это место
> полностью универсальным.
> 
> Зависимости на пакеты с другими модулями python надо прописывать как
> 
> Requires: python%__python_package_version-<anotherModule>
> 
> Могу оформить все это дело в виде отдельного макроса. Предложения по
> наименованию принимаются.

Помимо изложенного выше предложения, есть такой вариант:

%{python_versioned_name anotherModule}

а также
%__python_packagename python%__python_package_version

> Данные макросы никак не затрагивают эту область. То есть, метод
> сборки и упаковки определяется исключительно пэкеджером. Единственное
> условие - делать в конце %install unset RPM_PYTHON, чтобы исключить
> скорее всего нежелательную (повторную) байт-компиляцию. Хотя, конечно,
> сейчас этот самый RPM_PYTHON, по-хорошему, будет указывать именно на ту
> версию питона, для которой собирается пакет (даже если идет сборка по
> умолчанию)

Насколько я понимаю, компиляция после %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'ом).

> Дополнительные замечания по поводу сборки:
> 
> в данной схеме есть один, как мне кажется, недочет. Если некто
> пересобирает модуль вида 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. Точно так же, нет смысла в общем имени каталога
/usr/lib/python


> %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/


Не увидел проблем при использовании обычной схемы:


%build
CFLAGS="$RPM_OPT_FLAGS" python setup.py build

%install
python setup.py install \
       --optimize=%python_optlevel \
       --root=$RPM_BUILD_ROOT \
       --record=INSTALLED_FILES


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


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

-- 
Stay tuned,
  MhZ                                     JID: mhz на altlinux.org
___________
Daemon escaped from pentagram
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20040221/a9166354/attachment-0002.bin>