[devel] (was: Python Modules Policy)

[Alexey Morozov]

On Mon, Feb 16, 2004 at 04:02:07PM +0300, Andrey Orlov wrote:
> 1. Мы избавляемся от python23, ему на смену приходит python
> 2. Пакет python22 остается
> 3. В день выхода python24 мы делаем fork пакета python и пакет python23 
> появляется вновь, уже как вспомогательный
> 4. Пакет python принимает версию python-2.4.0
> 
> В этом случае мы можем ввести префикс версии, введя соотв. python-<MODULENAME>

> для основного пакета и python23-<MODULENAME> etc для всех остальных.
Я не против. Немного лишней работы, но, по крайней мере,
разруливаемо на уровне сборочных автоматов.

> И наш апгрейд всегда проходит гладко.
Да, видимо. Я не имею возражений по предлагаемой схеме.

То, что идет ниже, в общем, уже можно и не читать, просто ответы на
поставленные вопросы, которые уже неактуальны в свете вышеописанной
схемы.


> > 1. выработка адекватного для меня, как _пользователя_ Сизифа, механизма
> >    апгрейда питона
> Я не совсем понимаю, что такое механизм апгрейда адекватный для пользователя. 
> Сизиф предполагает единственный метод апгрейда - apt-get upgrade. Если мы не 
> ломаем возможность такого апгрейда бесчисленными форками - то это _работает_. 
> Я уже писал о том, что у меня не вызвало ни малейших проблем провести апгрейд 
> сервера.
Андрей, я повторяюсь, наверное, уже набил оскомину, но тем не менее:

_Когда_ Вы провели апгрейд сервера? Правильно, когда, _помимо_ питона,
собрали еще Zope, который, видимо, является одним из основных рабочих
средств для Вас. Причем, что характерно, переезд на Zope/python2.3 не
был безболезненным, и потребовал довольно много времени (здесь я
ориентируюсь исключительно на Ваши слова о степени работоспособности
новых сборок, поэтому заранее извините, если я чего-то недопонял)

А если человек пользуется, например, PyQt или еще какой-нибудь вещью,
которая не собрана/не собирается просто так под 2.3? Правильно, он
остается на 2.2. Никто не будет ставить "просто питон", нужен "питон/Zope",
"python/Twisted", "python/MySQL" итп.

При этом та схема, которую Вы предложили изначально (с жетским Conflicts
каждой следующей версии) вынуждает его холдить python на уровне 2.2. 
Причем, по мере увеличения количества питоновских модулей (и,
соответственно, увеличения времени пересборки всего под новый питон)
желания "апгрейдиться" будет становиться все меньше. Одним из следствий
этого является то, что число тестеров 2.3 сокращается, что, вообще говоря,
потенциально ухудшает сборку.

Далее в дело вступает фактор, когда мне реально требуется софтина XXX,
а она, в свою очередь, требует нового питона (при том, что проект мой -
на старом, например, потому что там [лучше] работает Zope или еще никто не
удосужился перебрать pygtk под 2.3). Что я делаю? Правильно, я ставлю
"Allow-Duplicated" и, таким образом, хороню идею автоматизированного
апгрейда. Спрашивается, за что боролись?


> Такой вариант вас устраивает? Меня, кажется, да.
Да, описанная Вами схема вполне приемлема для меня.

Касательно зависимостей на модули. Мне кажется, будет разумным, если
при "автоматической" сборке (т.е. python-<ModuleName>) межмодульные
зависимости оформляются как

Provides: python-<modulename>
Requires: python-<AnotherModule>

а при сборке "под устаревшую" версию:

Provides: pythonXY-<modulename>
Requires: pythonXY-<AnotherModule>

Итого мы автоматически получаем построения "правильных" по зависимостям
графов модулей, где зависимости не пересекаются.

Собственно говоря, механизмы, реализующие данную схему, _в общих чертах_
уже есть в моем _первом_ письме с прикрепленным файлом RPM-макросов.

----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?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/20040216/6a782ddd/attachment-0001.bin>