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

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

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

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.
> 

-- 

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


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