Alexey Tourbin пишет: > On Sun, Oct 28, 2007 at 07:10:14AM +0300, Aleksey Avdeev wrote: > >>>ПОЧЕМУ: сейчас дефолтный питон /usr/bin/python версии 2.4 и зависимости >>>у пакетов имеют вид python2.4(...). Если обновить дефолтный >>>/usr/bin/python на 2.5, то зависимости у всех остальных пакетов никуда >>>не денутся, они останутся python2.4(...). Теперь подумайте, что >>>получается, когда питон обновился, а скрипт, запускаемый через >>>/usr/bin/python имеет зависимости на питон 2.4, а на самом деле в >>>системе стоит питон 2.5. Например, этот скрипт для работы требует >>>что-то типа python2.4(gtk). Но при запуске через новый /usr/bin/python >>>эта зависимость как бы динамически трансформируется на python2.5(gtk). >>>То есть зависимость может быть формально удовлетворена, но получается >>>пшик, скрипт не запускается потому что уже нужен gtk'шный модуль для >>>2.5, а не для 2.4. >> >> Так может достаточно отделить мух от котлет? Например так: >> >>1. В системе есть /usr/bin/pythonX.Y. И их может быть несколько. >> >>2. В системе есть /usr/bin/python, как указатель на некоторый >>/usr/bin/pythonX.Y. И данная ссылка может предоставляться несколькими >>_взаимоконфликтующими_ пакетами. > > > Подобную схему изобретал Андрей Оролов. И достаточно весомо аргументировал её право на жизнь. (Более того -- мне пришлось столкнуться с её плюсами.) > > >>3. При сборке пакета со скриптами использующими /usr/bin/python -- >>добавляем в их зависимость на пакет предоставляющий /usr/bin/python в >>сборочной среде. В идеале, здесь желательно иметь ручку, отключающую >>данное поведение: её можно использовать для получения пакетов работающих >>с неким диапазоном версий питонов -- возможность поставить конфликты на >>те версии с которыми скрипт не работает у мантейнера останется. >> >> Тогда мы имеем с гуся следующее: >> >>1. Пакеты со скриптами использующими /usr/bin/pythonX.Y напрямую -- >>спокойно продолжают это делать, независимо от версии /usr/bin/python >>установленной в системе. >> >>2. Если в пакете используется /usr/bin/python -- при установке будет >>попытка вытянуть нужную версию (ту, с которой пакет был собран). Если >>это приведёт к конфликтам -- ставящий будет вынужден разрешить их в >>ручную (и это правильно). > > > *) > > >>3. Пакет которому необходим старый питон -- для не конфликтности с новым >>достаточно просто пропатчить. >> >>4. Возможно плавное замещение питона в дистрибутиве. (Но не на >>конкретной системе! Там, в прочем, возможен выбор _момента_ перехода.) > > > Невозможно, в силу *). Просто часть пакетов будет ставиться только > со старым питоном, часть -- только с новым. Часть пакетов вообще не > будет ставиться, потому что будет попытка поставить два питона. По моему это уже не технический аспект, а организационный: достаточно _явно_ указать в полиси что отсутствие пакета под текущий питон переводит его в статус, равнозначный его отсутствию (с некоторыми ограничениями, возможно). > > >>>Я делаю системное решение. То есть я исхожу из того, что все пакеты >>>В РЕПОЗИТАРИИ должны будут работать/починиться под новый питон. >>>Что там запускается из /home/user мне не особо интересно. Если там есть >>>что-то важное, то нужно это опакетить, и тогда придётся учитывать этот >>>пакет в плане миграции на питон 2.5. >> >> Этот вариант идеален, но я не чую его жизнеспособности в условиях >>ограниченности ресурсов. :-/ >> >> При вашем варианте имеем следующие грабли: >> >>1. Задержка на попадание нового питона в Сизиф, пока не будет >>оттестировано всё, что будет сочтено "ядром питона" > > > Думаю, что достаточно чтобы оно пересобралось с новым питоном. > Я не знаю, есть ли в питоновских пакетах привычка писать что-нибудь > вроде 'make test'. Это могло бы сделать первичное тестирование > существенно более предсказуемым. Теоретически -- да, это то к чему надо стремиться. Но случаи прикладной некромантии тоже существенны. > > >>2. При появлении нового питона в Сизифе -- часть приложений (что в >>"ядром питона" не вошла) "неожиданно" перестанет работать. > > > Они и так перестают работать. Достаточно пересобрать какой-нибудь > "средний" по топологии зависимостей питоновский модуль и вся иерархия > пакетов рассыпается -- возникает диверсия, при которой часть пакетов > относятся к старому питону, а часть -- уже к новому. Если это произошло после отмашки "текущий питон X.Y" -- то не вижу проблемы: в любом случаи не вижу способа избежать частичной разломанности репозитария. Возможно неплохим вариантом будет полиси аналогичное описывающему смену сонаме для библиотек. Например так: 1. Пакет для текущего питона называется python-<имя>. 2. Для питона отличного от текущего -- pythonX.Y-<имя>. > > >>3. Калуарность тестирования нового питона (т. к. помещать его в Сизиф, >>пока "ядром питона" не оттестировано/портировано -- нельзя). > > > Можно делать так как я делал с rpm-build. То есть запускаем тестовую > пересборку и смотрим какие есть проблемы. Решаем часть проблем, опять > запускаем тестовую пересборку. Проблем стало меньше. Тогда > окончательно пускаем в сизиф. Как при этом _простым_ образом решать проблемы с зависимостями от пакетов другого мантейнера? Да, git.alt часть проблем закроет... Но возможность вытащить из репозитария подходящий pythonX.Y-<имя> (если он уже есть), собранный его мантейнером, на мой взгляд не лишняя. > > Кулуарности никакой нет -- напротив, тому, кто за это взялся, придётся > очень много объяснять по поводу "типичных проблем" и т.д. > > >> Причём, за счёт того что для каждого использующего питон "ядром >>питона" своё, и с "ядром питона" коллег совпадать не обязано -- получаем >>источник конфликтов в рассылке... > > > "Ядро питона" это все про-питоновские пакеты в сизифе. > Минимальный план миграции -- просто пересобрать их с новым питоном. > Мне хотелось бы, чтобы при этом они ещё и работали. Для этого нужно > какое-то минимальное тестирование при СБОРКЕ. Хотя бы после сборки > попробовать загрузить питоном свежесобранные модули. > > То есть пересобираемость пакета должна давать минимальную гарантию > его работоспособности. Тогда получается технологичное решение. > Иначе, действительно, остается только "источник конфликтов в рассылке". Согласен. Но ручка для явного переключения на pythonX.Y всё равно не лишняя. -- С уважением. Алексей.