From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sun, 11 Jan 2004 09:28:20 +0600 From: Alexey Morozov To: ALT Devel discussion list Subject: Re: [devel] Re: [sisyphus] =?koi8-r?B?8MnU?= =?koi8-r?B?z87YySDNz8TVzNE=?= Message-ID: <20040111032820.GG12307@localhost.localdomain> References: <20040109153618.GQ2244@pyro.hopawar.private.net> <200401101250.56114.cray@neural.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RDS4xtyBfx+7DiaI" Content-Disposition: inline In-Reply-To: <200401101250.56114.cray@neural.ru> User-Agent: Mutt/1.4i Cc: sisyphus@altlinux.ru 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: Sun, 11 Jan 2004 08:59:46 -0000 Archived-At: List-Archive: List-Post: --RDS4xtyBfx+7DiaI Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit On Sat, Jan 10, 2004 at 02:58:19PM +0300, Andrey Orlov wrote: > Были у мня такие идеи, но я пришел к мнению, что это излишне. Все пакеты > нужно портировать на последнию версию питона, пакетов собранные > под старые версии не держать. Грустно. Почему - ниже. > Старые версии питона, типа python22 остаются > исключительно для целей разработки и тестирования, соответственно, > предполагается что те, кому они нужны - в состоянии пересобрать все > остальное сами. Не понятно, зачем тогда держать такой пакет, если пользоваться им все равно нельзя. > Затачивать дистрибутив под две версии питона, устанавливаемые по выбору, > я не вижу необходимости - это все-таки не emacs-nox vs emacs-X11, которые > имеют не пересекающиеся возможности, в данном случае python23 полностью > перекрывает python22, аналогичная ситуация была и с python21 vs python22. Тогда логичнее было бы делать так: python- python-compat Или вообще отказаться от -compat, как таковых. Заливать всю байду (питон и third-party модуля) разом при апдейте сизифиа и дело с концом. Но опять же, см. возражения ниже. > Надо будет посмотреть. Но, вообще гря, Zope пропатченный и собранный для > python22 иногда не собирался с python21. Точнее, собирался но не работал. > То же самое - MySQLdb. > Кроме того, зачастую новые версии пакетов затачиваются исключительно под > новую версию python и перестают пересобираться со старыми версиями, в них > так и пишут "required". Таким образом, пересобрать новую версию пакета под > оба питона сразу - в общем случе, нереально. %define _with_python --without-python прямо в спеке? > каждая из которых собирается своим компилятором. Если бы с питоном была > аналогичная проблема (например, Zope работающий исключительно с py21) - > я бы с вами согласился. Но, такой проблемы нет. То есть, Вы утверждаете, что обратная совместимость есть всегда, и ситуация, когда я при апгрейде питона и всех модулей получаю неработоспособное приложения, невозможна, или, во всяком случае, _крайне_ мало вероятна? Нет, мне это на самом деле крайне интересно знать. Как тогда это соотносится с: > положу 2.6.3 в сиз (завтра, наверно) кто им пользуется - будьте > поосторожнее. В отличие от моих патчей на Z2.6.2, патчи от разработчиков > изменили API некоторых продуктов (особенно в области секьюрити). Хотя эти > изменения можно считать "правильными", но при переходе можно осыпатся. Тут проблема очень простая, на самом деле. По своему предыдущему (непитоньему) опыту я знаю, что у каждого продукта, если это не наколенный скрипт для внутреннего потребления, есть maintaince cycle. То есть, грубо говоря, период, когда мы _вынуждены_ поддерживать ту версию программы, которую установили заказчику. Причем, поддерживать именно в том виде, в котором установили - максимум, мелкие патчи, которые не меняют приложение кардинально. Соответственно, каждое релиз, во-первых, четко позиционируется в дереве исходников (ну, у нас это таг+бранч в CVS'е + полиси на то, что можно с этим релизом делать, а что нельзя), а во-вторых, возможность воссоздания сборочной среды, чтобы не было неожиданностей. Для всяких монструозностей типа ACE/TAO это было более чем актуально, поскольку совместимости ни взад, ни вперед никто не обещал. Вопрос в том, насколько подобная довольно жесткая политика актуальна для питона и приложений на нем. У меня довольно мало практического опыта его использования. У меня сейчас, возможно, образуется ситуация, когда я буду просто не в состоянии говорить: "а мы с разработчиками тут переехали на новый [питон], он рулит, но со старым [питоном] совместимости больше нет, и давайте мы вам за _ваш_ счет произведём апгрейд". За свой, понятное дело, тоже не очень хочется :-)). Вот и подпрыгиваю :-). --RDS4xtyBfx+7DiaI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAAMLUX5DZdJn19V0RAlidAKCu8xmz6+2WE5BuYr2EGcbPgLBqTgCdFJ01 I9+SUy8ZWCVNZgDkBbkyAfY= =OM6z -----END PGP SIGNATURE----- --RDS4xtyBfx+7DiaI--