From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sun, 22 Feb 2004 06:05:00 +0600 From: Alexey Morozov To: Mikhail Zabaluev , devel@altlinux.ru, cray@neural.ru Subject: Re: [devel] Q: Python packaging howto Message-ID: <20040222000500.GB15706@localhost.localdomain> References: <20040220120041.GA2684@av1046.comex.ru> <20040221113726.GB29390@pyro.hopawar.private.net> <20040221182533.GB14716@av1046.comex.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cvVnyQ+4j833TQvp" Content-Disposition: inline In-Reply-To: <20040221182533.GB14716@av1046.comex.ru> User-Agent: Mutt/1.4.2.1i Cc: X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2004 00:26:31 -0000 Archived-At: List-Archive: List-Post: --cvVnyQ+4j833TQvp Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit 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- > > > > Могу оформить все это дело в виде отдельного макроса. Предложения по > > наименованию принимаются. > > Помимо изложенного выше предложения, есть такой вариант: > > %{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'а для того, чтобы > он получался сразу готовым к употреблению. Уже подправили. Только мне не очень понравилось качество кодирования. --cvVnyQ+4j833TQvp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAN/IsX5DZdJn19V0RAnMYAJ9sD5Jz8zWbXjp+CUwMQ8JxMtlK/ACfTX6z S13uYEcHRHkWbQhl1NF/n2I= =p7ZC -----END PGP SIGNATURE----- --cvVnyQ+4j833TQvp--