* Andrey Orlov [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@