[devel] Переходное полиси для для питона
Alexey Tourbin
=?iso-8859-1?q?at_=CE=C1_altlinux=2Eru?=
Вс Окт 28 04:58:54 MSK 2007
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.
> Подход, когда приложение может потребовать нужную версию питона --
> _мне_ нравится больше. Да, он сложнее в реализации. Но это то
> направление (по интерпретируемым языкам) в котором нужно двигаться.
То что нам с вами нравится это иногда имеет мало отношения к реальности.
То есть нам иногда нравятся противоречивые вещи, которые, строго говоря,
по-нормальному никак нельзя совместить.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип : application/pgp-signature
Размер : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20071028/52b96bdb/attachment-0002.bin>
Подробная информация о списке рассылки Devel