From: Alexey Morozov <alex-altlinux@idisys.iae.nsk.su> To: ALT Devel discussion list <devel@altlinux.ru> Cc: sisyphus@altlinux.ru Subject: Re: [devel] Re: [sisyphus] Питоньи модуля Date: Sun, 11 Jan 2004 09:28:20 +0600 Message-ID: <20040111032820.GG12307@localhost.localdomain> (raw) In-Reply-To: <200401101250.56114.cray@neural.ru> [-- Attachment #1: Type: text/plain, Size: 3798 bytes --] 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-<the last and shining version> python-compat<any previous version> Или вообще отказаться от -compat, как таковых. Заливать всю байду (питон и third-party модуля) разом при апдейте сизифиа и дело с концом. Но опять же, см. возражения ниже. > Надо будет посмотреть. Но, вообще гря, Zope пропатченный и собранный для > python22 иногда не собирался с python21. Точнее, собирался но не работал. > То же самое - MySQLdb. > Кроме того, зачастую новые версии пакетов затачиваются исключительно под > новую версию python и перестают пересобираться со старыми версиями, в них > так и пишут "required". Таким образом, пересобрать новую версию пакета под > оба питона сразу - в общем случе, нереально. %define _with_python<bad version> --without-python<bad version> прямо в спеке? > каждая из которых собирается своим компилятором. Если бы с питоном была > аналогичная проблема (например, Zope работающий исключительно с py21) - > я бы с вами согласился. Но, такой проблемы нет. То есть, Вы утверждаете, что обратная совместимость есть всегда, и ситуация, когда я при апгрейде питона и всех модулей получаю неработоспособное приложения, невозможна, или, во всяком случае, _крайне_ мало вероятна? Нет, мне это на самом деле крайне интересно знать. Как тогда это соотносится с: > положу 2.6.3 в сиз (завтра, наверно) кто им пользуется - будьте > поосторожнее. В отличие от моих патчей на Z2.6.2, патчи от разработчиков > изменили API некоторых продуктов (особенно в области секьюрити). Хотя эти > изменения можно считать "правильными", но при переходе можно осыпатся. Тут проблема очень простая, на самом деле. По своему предыдущему (непитоньему) опыту я знаю, что у каждого продукта, если это не наколенный скрипт для внутреннего потребления, есть maintaince cycle. То есть, грубо говоря, период, когда мы _вынуждены_ поддерживать ту версию программы, которую установили заказчику. Причем, поддерживать именно в том виде, в котором установили - максимум, мелкие патчи, которые не меняют приложение кардинально. Соответственно, каждое релиз, во-первых, четко позиционируется в дереве исходников (ну, у нас это таг+бранч в CVS'е + полиси на то, что можно с этим релизом делать, а что нельзя), а во-вторых, возможность воссоздания сборочной среды, чтобы не было неожиданностей. Для всяких монструозностей типа ACE/TAO это было более чем актуально, поскольку совместимости ни взад, ни вперед никто не обещал. Вопрос в том, насколько подобная довольно жесткая политика актуальна для питона и приложений на нем. У меня довольно мало практического опыта его использования. У меня сейчас, возможно, образуется ситуация, когда я буду просто не в состоянии говорить: "а мы с разработчиками тут переехали на новый [питон], он рулит, но со старым [питоном] совместимости больше нет, и давайте мы вам за _ваш_ счет произведём апгрейд". За свой, понятное дело, тоже не очень хочется :-)). Вот и подпрыгиваю :-). [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-01-11 3:28 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-01-10 11:58 ` Andrey Orlov 2004-01-11 3:28 ` Alexey Morozov [this message] 2004-01-11 10:45 ` Andrey Orlov 2004-01-11 19:23 ` [devel] Re: [sisyphus] ðÉÔÏÎØÉ ÍÏÄÕÌÑ Alex Ott 2004-01-11 21:07 ` [devel] Re: [sisyphus] Питоньи модуля Andrey Orlov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20040111032820.GG12307@localhost.localdomain \ --to=alex-altlinux@idisys.iae.nsk.su \ --cc=devel@altlinux.ru \ --cc=sisyphus@altlinux.ru \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git