From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 14 Jan 2004 21:04:40 +0600 From: Alexey Morozov To: ALT Devel discussion list Subject: Re: [devel] =?koi8-r?B?88LP0svBINDBy8XU?= =?koi8-r?B?z9csINPPxMXS1sHdycg=?= .py Message-ID: <20040114150439.GB2227@pyro.hopawar.private.net> References: <20040113130237.GA2227@pyro.hopawar.private.net> <20040113131618.GA7531@basalt.office.altlinux.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MW5yreqqjyrRcusr" Content-Disposition: inline In-Reply-To: <20040113131618.GA7531@basalt.office.altlinux.org> User-Agent: Mutt/1.4i Cc: Python Development Team X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.3 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: Wed, 14 Jan 2004 15:04:48 -0000 Archived-At: List-Archive: List-Post: --MW5yreqqjyrRcusr Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit 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- прежде всего для удобства этого самого тестирования. В принципе, всю машинерию по "два пакета из одного srpm'а" можно убрать, но, мне кажется, различие по версиям стоит сохранить, хотя бы для тех, кому по каким-то причинам понадобилось _локально_ держать обе версии питона (н-р, на время переезда на следующую версию) Twisted собрал, но его нужно будет пилить на подпакеты по зависимостям, чтобы не тянуть за собой на сервер всякие gtk и прочие Qt. Кстати, есть ли для питона rpm-скрипты, аналогичные perl.req или perl.prov? Задача-то более решаема, на первый взгляд, чем для перла... --MW5yreqqjyrRcusr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFABVqHX5DZdJn19V0RAjJZAJwNG0/RirIlNZm84YgSoJxn1sdkFgCfX9i9 I1MYOx+V5rJOqs4k+9xtpT4= =Dfyj -----END PGP SIGNATURE----- --MW5yreqqjyrRcusr--