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 --]
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-09 15:36 Alexey Morozov
2004-01-09 16:41 ` Алексей Любимов
2004-01-09 20:09 ` Alexey Morozov
2004-01-10 11:58 ` Andrey Orlov
2004-01-11 3:28 ` Alexey Morozov [this message]
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 Sisyphus discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/sisyphus/0 sisyphus/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 sisyphus sisyphus/ http://lore.altlinux.org/sisyphus \
sisyphus@altlinux.ru sisyphus@altlinux.org sisyphus@lists.altlinux.org sisyphus@lists.altlinux.ru sisyphus@lists.altlinux.com sisyphus@linuxteam.iplabs.ru sisyphus@list.linux-os.ru
public-inbox-index sisyphus
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.sisyphus
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git