Re: [devel] Переходное полиси для для питона

[Alexey Tourbin <at@altlinux.ru>]

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

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. При появлении нового питона в Сизифе -- часть приложений (что в
> "ядром питона" не вошла) "неожиданно" перестанет работать.

Они и так перестают работать.  Достаточно пересобрать какой-нибудь
"средний" по топологии зависимостей питоновский модуль и вся иерархия
пакетов рассыпается -- возникает диверсия, при которой часть пакетов
относятся к старому питону, а часть -- уже к новому.

> 3. Калуарность тестирования нового питона (т. к. помещать его в Сизиф,
> пока "ядром питона" не оттестировано/портировано -- нельзя).

Можно делать так как я делал с rpm-build.  То есть запускаем тестовую
пересборку и смотрим какие есть проблемы.  Решаем часть проблем, опять
запускаем тестовую пересборку.  Проблем стало меньше.  Тогда
окончательно пускаем в сизиф.

Кулуарности никакой нет -- напротив, тому, кто за это взялся, придётся
очень много объяснять по поводу "типичных проблем" и т.д.

>   Причём, за счёт того что для каждого использующего питон "ядром
> питона" своё, и с "ядром питона" коллег совпадать не обязано -- получаем
> источник конфликтов в рассылке...

"Ядро питона" это все про-питоновские пакеты в сизифе.
Минимальный план миграции -- просто пересобрать их с новым питоном.
Мне хотелось бы, чтобы при этом они ещё и работали.  Для этого нужно
какое-то минимальное тестирование при СБОРКЕ.  Хотя бы после сборки
попробовать загрузить питоном свежесобранные модули.

То есть пересобираемость пакета должна давать минимальную гарантию
его работоспособности.  Тогда получается технологичное решение.
Иначе, действительно, остается только "источник конфликтов в рассылке".

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