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

Вс Окт 28 15:36:00 MSK 2007

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 всё равно не
лишняя.

-- 

С уважением. Алексей.

----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 548 байтов
Описание: OpenPGP digital signature
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20071028/8aa02329/attachment-0002.bin>