From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Andrey Orlov To: sisyphus@altlinux.ru, devel@altlinux.ru Date: Sat, 10 Jan 2004 14:58:19 +0300 User-Agent: KMail/1.5.4 References: <20040109153618.GQ2244@pyro.hopawar.private.net> In-Reply-To: <20040109153618.GQ2244@pyro.hopawar.private.net> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200401101250.56114.cray@neural.ru> Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit Cc: Subject: [devel] Re: [sisyphus] =?koi8-r?b?8MnUz87YySDNz8TVzNE=?= 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: Sat, 10 Jan 2004 12:00:37 -0000 Archived-At: List-Archive: List-Post: Hi! Если кратко - проблема поставлена интересная, но конкретно к ситуации с питоном такой подход излишен. Далее подробно. On Friday 09 January 2004 18:36, Alexey Morozov wrote: > Во-вторых, коль скоро у нас одновременно болтаются две и более версии > питона, причем, модули для них тоже нужно собирать отдельно, то в имя > пакета вносится и версия питона. Были у мня такие идеи, но я пришел к мнению, что это излишне. Все пакеты нужно портировать на последнию версию питона, пакетов собранные под старые версии не держать. Старые версии питона, типа python22 остаются исключительно для целей разработки и тестирования, соответственно, предполагается что те, кому они нужны - в состоянии пересобрать все остальное сами. Затачивать дистрибутив под две версии питона, устанавливаемые по выбору, я не вижу необходимости - это все-таки не emacs-nox vs emacs-X11, которые имеют не пересекающиеся возможности, в данном случае python23 полностью перекрывает python22, аналогичная ситуация была и с python21 vs python22. > По поводу построения, я нацарапал нечто, что собирает из одного src.rpm > (python-ZSI-1.4.1-alt2.src.rpm) один или два бинарных модуля, в Надо будет посмотреть. Но, вообще гря, Zope пропатченный и собранный для python22 иногда не собирался с python21. Точнее, собирался но не работал. То же самое - MySQLdb. Кроме того, зачастую новые версии пакетов затачиваются исключительно под новую версию python и перестают пересобираться со старыми версиями, в них так и пишут "required". Таким образом, пересобрать новую версию пакета под оба питона сразу - в общем случе, нереально. Тем более автоматически. Надо либо откатываться на старую версию, либо делать бакпорт. > Комментарии? Излишне: затраты времени на поддержку не окупятся иллюзорным выигрышем, который для пользователя морально-устаревшего компилятора (интерпретатора) очень быстро грозит обернутся проигрышем. Исключения бывают - типа двух gcc в нашем дистрибутиве - но, насколько я понимаю, дублирования пакетов там не происходит - софт разбит на две группы, каждая из которых собирается своим компилятором. Если бы с питоном была аналогичная проблема (например, Zope работающий исключительно с py21) - я бы с вами согласился. Но, такой проблемы нет. Подводя итог: Наиболее предпочтительный вариант - иметь только последний питон. Т.е. я бы python22 вообще выкинул. Но для тестирования - полезно. Все свои проекты и продукты я перевел на 23 и вам советую сделать тоже самое (все-таки на это был почти год времени). На самом деле, на сегодняшний день я не вижу ни одной реальной потребности пользоваться устаревшим интерпретатором. Даже Zope, при всей любви его разработчиков к реликтовому софту, начиная с версии 2.6.3 пропатчен ими до python23. Кстати, я скоро положу 2.6.3 в сиз (завтра, наверно) кто им пользуется - будьте поосторожнее. В отличие от моих патчей на Z2.6.2, патчи от разработчиков изменили API некоторых продуктов ( особенно в области секьюрити). Хотя эти изменения можно считать "правильными", но при переходе можно осыпатся. -- WthBstRgrds -- Андрей Орлов -- --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org --- ----------------------------------------