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

[Aleksey Avdeev <solo@solin.spb.ru>]

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

Alexey Tourbin пишет:
> On Sun, Oct 28, 2007 at 03:56:47AM +0300, Aleksey Avdeev wrote:
> 
>>>Если отбросить практическую причину (что программа сборки дополнительных
>>>модулей в двух экземлярах так никгода и не была даже частично
>>>реализована),
>>
>>  Но _принципиальная_ возможность её реализации присутствовала. И это --
>>главное.
> 
> 
> Принципиальная возможность есть всегда.
> Другое дело, насколько это вписывается в дизайн репозитария.
> 
> 
>>>то всё равно это никак нельзя по-нормальному сделать на
>>>уровне rpm-зависимостей.  То есть если /usr/bin/python висит на
>>>альтернативах, то эта альтернатива динамически переключает зависимости
>>>вида pythonX.Y(...) на pythonX.Z(...).  Я про это в свое время много спорил.
>>
>>1. Можно напомнить суть споров? (Что-то не найду их в своём архиве...
>>Похоже не так ищу.)
>>
>>2. Если не нравится /usr/bin/python на альтернативах, то может стоит
>>использовать вариант взаимоконфликтующих пакетов? (В смысле:
>>/usr/bin/pythonX и /usr/bin/pythonY спокойно уживаются вместе, но пакет
>>содержащий /usr/bin/python может быть только один.)
> 
> 
> Сумбурно отвечаю сразу на два вопроса.  Если хотим иметь два питона
> в репозитарии, то никак не получается нормально сделать дефолтный
> /usr/bin/python.  То есть нужно отказаться от /usr/bin/python ВООБЩЕ
> и оставить только /usr/bin/pythonX.Y и /usr/bin/pythonX.Z.

  C этим пунктом согласен.

> 
> Но отсутствие дефолтного питона явно не в интересах репозитария.

  И с этим -- тоже.

> 
> ПОЧЕМУ: сейчас дефолтный питон /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>... А это не тот стиль, который стоит
>>провоцировать (приходилось сталкиваться с таким, на предыдущей работе).
> 
> 
> Я делаю системное решение.  То есть я исхожу из того, что все пакеты
> В РЕПОЗИТАРИИ должны будут работать/починиться под новый питон.
> Что там запускается из /home/user мне не особо интересно.  Если там есть
> что-то важное, то нужно это опакетить, и тогда придётся учитывать этот
> пакет в плане миграции на питон 2.5.

  Этот вариант идеален, но я не чую его жизнеспособности в условиях
ограниченности ресурсов. :-/

  При вашем варианте имеем следующие грабли:

1. Задержка на попадание нового питона в Сизиф, пока не будет
оттестировано всё, что будет сочтено "ядром питона"

2. При появлении нового питона в Сизифе -- часть приложений (что в
"ядром питона" не вошла) "неожиданно" перестанет работать.

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

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

> 
> 
>>  Подход, когда приложение может потребовать нужную версию питона --
>>_мне_ нравится больше. Да, он сложнее в реализации. Но это то
>>направление (по интерпретируемым языкам) в котором нужно двигаться.
> 
> 
> То что нам с вами нравится это иногда имеет мало отношения к реальности.
> То есть нам иногда нравятся противоречивые вещи, которые, строго говоря,
> по-нормальному никак нельзя совместить.

  Но это не значит, что таких путей искать не нужно.

-- 

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 548 bytes --]