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.

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

ПОЧЕМУ: сейчас дефолтный питон /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.

>   Мне активно не нравиться эта идея, т. к. на практике приведёт к тому,
> что нужный для конкретного приложения питон (и само приложение) будет
> развёрнут в /home/<user>... А это не тот стиль, который стоит
> провоцировать (приходилось сталкиваться с таким, на предыдущей работе).

Я делаю системное решение.  То есть я исхожу из того, что все пакеты
В РЕПОЗИТАРИИ должны будут работать/починиться под новый питон.
Что там запускается из /home/user мне не особо интересно.  Если там есть
что-то важное, то нужно это опакетить, и тогда придётся учитывать этот
пакет в плане миграции на питон 2.5.

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

То что нам с вами нравится это иногда имеет мало отношения к реальности.
То есть нам иногда нравятся противоречивые вещи, которые, строго говоря,
по-нормальному никак нельзя совместить.