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=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.5 From: Alexey Morozov To: devel@lists.altlinux.org Date: Tue, 2 Feb 2010 16:54:18 +0600 User-Agent: KMail/1.12.4 (Linux/2.6.30-std-def-alt14; KDE/4.3.4; i686; ; ) References: <8d778a621001301748o389479bdncd68d131b4dc8778@mail.gmail.com> <201002010003.15108.morozov@altlinux.org> <20100202060656.GE7665@wrars-comp.wrarsdomain> In-Reply-To: <20100202060656.GE7665@wrars-comp.wrarsdomain> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <201002021654.18586.morozov@altlinux.org> Subject: Re: [devel] python3.x(qwe) vs python3(qwe) 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: Tue, 02 Feb 2010 10:54:40 -0000 Archived-At: List-Archive: List-Post: В сообщении от Вторник 02 февраля 2010 12:06:56 автор Andrey Rahmatullin написал: > On Mon, Feb 01, 2010 at 12:03:14AM +0600, Alexey Morozov wrote: > > Тогда надо кардинально менять схему упаковки. В своём нынешнем виде и > > заявленных целях (кстати, если не секрет, есть где-нибудь место, где эти > > цели явно проартикулированны?) > > Только не говори, что ты не имеешь отношения к нашему Python Policy. Оно прокисло и как минимум в одном важном пункте не соблюдается. Так что, можно считать его практически несущественным, хотя, _возможно_ , и интересным с исторической точки зрения. На мой взгляд, основная проблема нынешней схемы: с одной стороны, используются механизмы привязывания модуля к определённой версии при сборке пакета (собственно, для большинства модулей эти механизмы вытекают из схемы их расположения, %_libdir/pythonX.Y, а для меньшей части - из привязок к libpython). При этом, замечу, основная цель выбранного расположения, - борьба с несовместимостями между версиями и архитектурами в питоньем байткоде, - выглядит для меня достаточно умозрительной here and now. с другой стороны, заложенную при написании питон-полиси схему с множественным питоном и плавной, итеративной миграцией модулей, благополучно пристрелили. В общем, она и вправду, видимо, того стоила, но, факт, необходимость множественности питонов напрямую следует из сформулированных _тогда_ целей. Как из этого выходить? Фиг знает. Можно, например, отказаться от принципа "инсталлируется apt'ом - значит работоспособно" (да-да, я знаю, что это плохо :) ). Кстати, вероятнее всего, 90-ста процентам тех пакетов, которые используют питон в качестве языка скриптования, совсем необязателен "полноценный питон" со сколько-нибудь полной библиотекой, достаточно libpython. Соответственно, масштаб революции в репозитории можно будет сильно уменьшить, если в момент заливки нового питона предоставлять libpython-compat для уходящей версии. Второй вариант - научиться автоматически блокировать в репозитории пакеты, которые явно или неявно связаны с питоном, чтобы заливка новой версии не превращалась в увлекательную игру с Ахиллесом и черепахой в главных ролях. Но тут, чес-гря, я не знаю, каковы будут трудозатраты на реализацию такого решения. Дебиановцы, повторюсь, пошли по третьему пути. source-level пакеты распространяются в виде .py, которые при инсталляции раскладываются вместе со сгенерёнными тут же .pyc в каталоги, соответствующие установленным на конкретной машине версиям python'а. Отдельно решается вопрос с архитектурно- зависимыми, "бинарными" пакетами. Насколько я понимаю, на сегодняшний день у них наиболее чётко проработана схема с поддержкой нескольких версий питона одновременно, и эта схема как никакая другая рассчитана на независимую, "распределённую" процедуру обновления пакетов в репозитории. В том числе, и обновлении питона и его запчастей. Ну, в общем, как-то так. Собственно, когда я спрашивал о явном проговаривании целей, я подразумевал, что такое проговаривание позволит понять, какие решения являются абсолютно необходимыми, а от каких можно и нужно безболезненно отказаться. АМ