On Fri, Oct 26, 2007 at 10:56:13PM +0400, Peter V. Saveliev wrote:
> > В обозримом будущем планируется переход на питон 2.5.
> > В связи с этим дальше лелеять надежны насчёт двух питонов я не вижу
> > смысла.
> 
> * а ничего, что некоторые программы работают только с 2.4?
> * в частности, я смогу подгонять свой проект под 2.5 только после его 
> появления в Сизифе, по хорошему, т.к. времени, чтобы ставить Debian, просто 
> не остаётся

Уже вышел python 2.5.1 (некоторое время назад).  Все кому надо за это
время должны были "подтянуться" (из апстримов по крайней мере).
Собственно, в свое время я был против перехода на на python 2.5(.0)
как раз потому, что (наверное) не все были готовы.  Но теперь время
будет "играть" в обратную сторону.  Есть ведь и обратная проблема:
апстримы уже не будут сохранять совместимость с 2.4.

> Есть объективная причина, которая исключает наличие двух питонов? Или это как 
> с biarch, "некошерно, потому что у нас такого нет", а не наоборот?

Если отбросить практическую причину (что программа сборки дополнительных
модулей в двух экземлярах так никгода и не была даже частично
реализована), то всё равно это никак нельзя по-нормальному сделать на
уровне rpm-зависимостей.  То есть если /usr/bin/python висит на
альтернативах, то эта альтернатива динамически переключает зависимости
вида pythonX.Y(...) на pythonX.Z(...).  Я про это в свое время много спорил.

Можно будет оставить "чисто запасной" python2.4 с отключенным поиском
питоновских зависимостей и без /usr/bin/python (только с
/usr/bin/python2.4).  Может кто-нибудь этим займется ввиду суровой
необходимости.

К тому же, схема зависимостей pythonX.Y(...) не дает возможность делать
noarch пакеты, которые не должны зависеть от версии python'а.  По идее у
таких пакетов должен быть Provides: python(...).  То как тогда ставить
комплементарный Requires: python(...) или pythonX.Y(...) ?

То есть я полагаю что будет сделано так: будет всего один питон;
будет сделан /usr/share/python/site-packages; все зависимости будут
иметь вид python(...); компилированные пакеты будут дополнительно
иметь зависимость на libpythonX.Y.so.M.N.  Вопрос с совместимостью
версии байткода в noarch пакетах кажется мне непринципиальным -- если
версия байткода в *.pyc не совпадает, питон просто будет загружать *.py.

Всё это будет не в ближайшее время, наверное в следующем году.
Но кое-что к этому уже готово.  Поскольку очень маловероятно,
чтобы кто-то таки начал собирать модули для разных питонов из одного
spec-файла (в чем соль старого полиси), я пока просто предлагаю
постепенно "подчистить" spec-файлы.  Когда наступит час X, придётся
меньше переделывать, часть пакетов можно будет просто пересобрать.