[devel] Переходное полиси для для питона
Aleksey Avdeev
=?iso-8859-1?q?solo_=CE=C1_solin=2Espb=2Eru?=
Вс Окт 28 03:56:47 MSK 2007
Alexey Tourbin пишет:
> On Fri, Oct 26, 2007 at 10:56:13PM +0400, Peter V. Saveliev wrote:
>
...
>
> Если отбросить практическую причину (что программа сборки дополнительных
> модулей в двух экземлярах так никгода и не была даже частично
> реализована),
Но _принципиальная_ возможность её реализации присутствовала. И это --
главное.
> то всё равно это никак нельзя по-нормальному сделать на
> уровне rpm-зависимостей. То есть если /usr/bin/python висит на
> альтернативах, то эта альтернатива динамически переключает зависимости
> вида pythonX.Y(...) на pythonX.Z(...). Я про это в свое время много спорил.
1. Можно напомнить суть споров? (Что-то не найду их в своём архиве...
Похоже не так ищу.)
2. Если не нравится /usr/bin/python на альтернативах, то может стоит
использовать вариант взаимоконфликтующих пакетов? (В смысле:
/usr/bin/pythonX и /usr/bin/pythonY спокойно уживаются вместе, но пакет
содержащий /usr/bin/python может быть только один.)
>
> Можно будет оставить "чисто запасной" python2.4 с отключенным поиском
> питоновских зависимостей и без /usr/bin/python (только с
> /usr/bin/python2.4). Может кто-нибудь этим займется ввиду суровой
> необходимости.
>
> К тому же, схема зависимостей pythonX.Y(...) не дает возможность делать
> noarch пакеты, которые не должны зависеть от версии python'а. По идее у
> таких пакетов должен быть Provides: python(...). То как тогда ставить
> комплементарный Requires: python(...) или pythonX.Y(...) ?
>
> То есть я полагаю что будет сделано так: будет всего один питон;
^^^^^^^^^^^^^^^^^^^^^^
Мне активно не нравиться эта идея, т. к. на практике приведёт к тому,
что нужный для конкретного приложения питон (и само приложение) будет
развёрнут в /home/<user>... А это не тот стиль, который стоит
провоцировать (приходилось сталкиваться с таким, на предыдущей работе).
Подход, когда приложение может потребовать нужную версию питона --
_мне_ нравится больше. Да, он сложнее в реализации. Но это то
направление (по интерпретируемым языкам) в котором нужно двигаться.
> будет сделан /usr/share/python/site-packages; все зависимости будут
> иметь вид python(...); компилированные пакеты будут дополнительно
> иметь зависимость на libpythonX.Y.so.M.N. Вопрос с совместимостью
> версии байткода в noarch пакетах кажется мне непринципиальным -- если
> версия байткода в *.pyc не совпадает, питон просто будет загружать *.py.
>
--
С уважением. Алексей.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : signature.asc
Тип : application/pgp-signature
Размер : 548 байтов
Описание: OpenPGP digital signature
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20071028/0a979b7a/attachment-0002.bin>
Подробная информация о списке рассылки Devel