[devel] Python Modules Policy: (was: alternatives && postfix)

[Andrey Orlov]

On Tuesday 10 February 2004 13:15, Alexey Morozov wrote:
> 1. Он проставляет Obsoletes: pythonN в python{N+1} или делает
>    аналогичные изменения, о точном решении будет сообщено
>    дополнительно ориентировочно в конце недели.

В конце недели я занимался персборкой "кстати" вышедшего Z264, так
что с Obsoletes / Conflicts разобрался только-только. Я поставил Conflicts.
Причины и подробное описание будут в отдельном письме, тестовый пакет 
в дедалусе будет сегодня или завтра.

> 2. _Одновременная_ сборка пакетов под разные версии питона является
>    на данный момент ненужной ввиду своей трудоемкости.
> 3. Андрей думает над целесообразностью сборки пакетов вида
>    python<N>-ModuleName из исходника вида python-ModuleName

Пункты 2, 3 разрушают юзабельность решения с поддержкой и менеджментом
пакетов, основанной на использовании APT / RPM. Я крайне сожалею, но я против.
Подробности опять-таки в отдельном письме.

Вместо такого подхода более реальный и работающий - держать отдельный репозиторий
для исторического хлама, в который списывается пакет для py2.N в момент выхода пакета
для py2.N+1. 

> 4. Я выкладываю на woland свой текущий вариант спеков, попутно
>    думая над "полезными макросами"

Спек я посмотрел. Он мне понравился, хотя п.2,3 ставят его ценность под сомнение.
В тоже  время, если мы все-таки сохраним идею использования двух питонов (в чем
лично я очень сильно сомневаюсь), он может иметь ограниченное применения для
пересборки "почти обязательных" модулей (Например, коннекторов к базам данных). 

> 5. В полиси для питоньих модулей вносится обязательный
>    Requires: python = %<pversion>, где %<pversion> совпадает с
>    %__python_version того питона, для которого производилась сборка.

Т.е. то, что имеет место сейчас.

> Предлагается подумать над следующими двумя полиси:
> 6. Программы на python, не зависящие от конкретной версии питона
> 7. Программы, имеющие такую привязку (н-р, идущие вместе с конкретной

Я в принципе против обеих пунктов и уже устал объяснять почему: программ не зависящих
от конкретной версии питона не существует в природе. То, что у нас сейчас сделано
на альтернативах - значительно лучше. Обратите внимание на работу пакетов python23-tools-idle,
etc. Пока альтернатива цела - все OK. Что я думаю о тех, кто правит альтернативы руками
и копирует файлы из каталого в каталог минуя RPM, объяснять, очевидно, не надо. В любом
случае, с учетом текущего указания conflicts установка обоих питонов простым пользователем
становится невозможный, а "те, кому очень надо" как-нить разберутся.

> 8. Некоторое время назад Андрей предлагал в "боевых" пакетах таскать
>    только байткод, а .py заворачивать в отдельные пакеты "для

Размышления о байткоде ушли отдельным письмом.

Подытоживая выше сказанное, и чбы подвести итог под остальными письмами, я должен сказать:
я лишний раз убедился в том, что идея держать два "работоспособных" питона в дистрибутиве -
ошибочна в принципе, так как приводит к неразрешимому снижению юзабельности APT/RPM.
Иными словами, я остаюсь при своем мнении: питонN.M-1 должен использоваться только 
разработчиками devel@ и только в процессе перехода на pythonN.M. 

Что до потребностей разработки под старые платформы и т.п. - я предлагаю перевести все
размышления в другое русло: отдельный репозиторий для пакетов, имеющих историческую ценность.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray на neural.ru, jid: cray на altlinux.org ---
----------------------------------------