From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00, FUZZY_XPILL, SPF_PASS autolearn=no version=3.2.5 From: Alexey Morozov To: ALT Linux Team development discussions Date: Wed, 30 Sep 2009 10:25:04 +0700 User-Agent: KMail/1.12.1 (Linux/2.6.30-std-def-alt12; KDE/4.3.1; i686; ; ) References: <921f6bb40909291128x2e24bc1xd7b42171ef71b68b@mail.gmail.com> In-Reply-To: <921f6bb40909291128x2e24bc1xd7b42171ef71b68b@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 8bit Message-Id: <200909301025.04867.morozov_ml@ngs.ru> Subject: Re: [devel] Python Policy (was: Re: [SCM] packages/newt: heads/sisyphus) X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 03:27:29 -0000 Archived-At: List-Archive: List-Post: Здравствуйте. В сообщении от Среда 30 сентября 2009 01:28:49 автор Evgeny Sinelnikov написал: > 1. Есть ли возражения относительно подхода, когда в все пакеты с > питоновскими модулями будут именоваться pythonX.Y-module-%{name}? Я > предлагаю отказаться от "чистых" имён в пользу удобства именования и > однозначности при переездах на новые питоны. Если интересно, заметная часть питон-модулей (включая .pyc/.pyo!) преспокойно переезжает из pythonX.Y в pythonX. . Исключения составляют те, кто завязан на libpython.so и другие ELF-библиотеки. Поэтому, как мне кажется, было бы разумнее, если бы бОльшая часть питон-модулей лежала где-нибудь в /usr/share/pythonX. Ну и остаётся некоторый риск того, что в каком-то из минорных апдейтов (слегка) сломают совместимость по байткоду. Альтернативный подход применён в Debian Python Policy. У них предкомпиляция байткода осуществлялась, если я правильно помню, на машине конечного пользователя (на этапе dpkg-configure), в каталогах, специфичных для данной версии питона. Посмотрите, кстати, может, и велосипед не надо изобретать :) > 2. Кто будет осуществлять поддержку python policy на уровне rpm? > Python Team? Если да, то прошу помочь реализовать средство подстановки > точной версии питона в shabang для скриптов. Сейчас я не совсем > понимаю куда это лучше встроить и как это должно работать. Для меня > это одно из основных препятствий для тестирования двух питонов. Вообще говоря, это осуществляется стандартными питоновскими distutils & Co. Достаточно просто запускать не /usr/bin/python, а /usr/bin/pythonX.Y. Собственно говоря, и зависимость на точную версию python пробивалась именно поэтому - во всех скриптах, которые зависели от установленных в /usr/lib/python/X.Y модулей, в хэшбэнге был именно pythonX.Y.