Re: [devel] Переход на новый python

["Alexey I. Froloff" <raorn@immo.ru>]

[-- Attachment #1: Type: text/plain, Size: 3928 bytes --]

* Andrey Orlov <cray@> [050316 16:12]:
> Теперь подробно. 
[..skip..]
> Если же вам libpython2.3 нужна для чего-то еще, то .... вам
> придется чем-то пожертвовать.
Ну, мы вчера в jabber этот вопрос уже обсуждали...

Если питон один, то почему их три?  Зачем нужно держать в
репозитарии три версии питона? (Андрей, если напрягает, пропусти
пять абзацев ;-)

$ locate -r SRPMS/python-\?2
/var/ftp/pub/distributions/ALTLinux/Sisyphus/files/SRPMS/python-2.4.0-alt5.src.rpm
/var/ftp/pub/distributions/ALTLinux/Sisyphus/files/SRPMS/python2.3-2.3.4-alt7.src.rpm
/var/ftp/pub/distributions/ALTLinux/Sisyphus/files/SRPMS/python22-2.2.3-alt8.1.1.src.rpm

Для меня количество питонов определется количеством пакетов,
провайдящих python-devel - количество вариантов сборки чего-либо.
Сейчас выбор варианта делается через зависимость на
python-devel=%_python_version...

После появления python-2.4.0 и переименования python-2.3.x ->
python2.3 все попытки собрать пакеты с python2.3 были об'явлены
противозаконными и нарушающими права человека.  Отсюда
получается, что есть смысл держать в репозитарии один
пакет python-devel последней версии.

Едем дальше.  Все пакеты, предоставляющие или зависимые от
питоньих модулей имеют версию питона в зависимостях
(pyhtonX.Y(blah)).  Отсюда получается, что python2.3 нужен только
на момент перехода на новый питон, чтобы не плодить сто тыщщ
мульёнов unmet'ов.

Андрей, я помню, что есть люди, которые хотят странного.  Считаем
вышенаписаное моим занудством.


Далее, зависимость на libpythonX.Y.so.x.y как правило означает
что пакет может использовать какие-то возможности языка python.
Как правило это опционально.  См. напр. vim, OOo, xchat,
gnumeric, zapping...

Сейчас libpythonX.Y.so.x.y лежит в python-base, python-base сам
по себе требует python=%__python_version, python-strict
конфликтует с python не своей версии.

Если развернуть зависимости следующим образом:

python-base может быть установлен сам по себе.
python хочет python-base=%__python_version
python-strict по прежнему конфликтует с python не своей версии.

Это решит следующие проблемы:

+ установка пакета, использующего embedded python не приведёт к
установке python-strict/relaxed/whatever если не требуются
дополнительные модули (как правило задействуются они из
вспомогательных скриптов на языке python).

+ можно одновременно поставить две непересекающиеся по файлам
версии python-base если этого требуют межпакетные зависимости и
тем более зависимости на SONAME у исполняемых файлов.  Мне
кажется, что на момент перехода можно допустить _частичную_
потерю функциональности у некоторых пакетов.  По крайней мере они
не будут унесены из системы во время перехода на новый python...

Вариант, когда у пакета есть зависимости на libpythonX.Y.so.x.y и
одновременно на pythonZ.C(blah) мне представляется маловероятным.


По поводу автоматической пересборки...  Да, я помню что некоторые
пакеты не работали при после автоматической пересборки с новым
python (2.2 это был кажется?), но у программ, которые встраивают
в себя питон немного другая ситуация.

Если изменился API программа просто автоматически не
пересоберётся, о чём мантейнер будет уведомлён и уже сам будет с
этим разбираться.  Если программа пересобралась, она запустится.
Я не думаю, что Гвидо настолько отмороженый на голову, чтобы
делать какие-то радикальные изменения, незаметные обычному
пользователю libpython (как это недавно случилось с libncurses)...

Поэтому есть смысл натравливать QA робота на все пакеты,
зависящие от libpythonX.Y.so.x.y сразу после появления нового
python в репозитарии.  Возможно с поправкой - зависящие от
libpythonX.Y.so.x.y и не зависясище от pythonX.Y(*)...

-- 
Regards, Sir Raorn.
-------------------
> Помогите решить проблему с проигрыванием midi. KMid и playmidi
...все равно не переиграют TiMidity++? ;-)
		-- mike in community@

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]