[devel] Python-2.6

[Ivan Fedorov]

Evgeny Sinelnikov <sin-u2l5PoMzF/Uox3rIn2DAYQ �� public.gmane.org> writes:

>>>
>>> Второй вариант не брать на себя столько ответственности, что не унести
>>> и за раз, и за два, и за три... Стандартный путь - сделать
>>> compat-пакет... Всё будет продолжать устанавливаться, но собираться
>>> уже не будет... Этот вариант крайне не приятен для пересборки новых
>>> пакетов, которые как бы не причём...
>> есть проблема - у нас есть N пакетов, которые зависят от libpython, если
>> часть модулей будет под 2.5, а часть под 2.6 то у нас для таких пакетов
>> не будет доступен определённый набор модулей, что плохо.
>>
>
> Ну, ужас... Но ведь не ужас, ужас, ужас... :)
ну это кому как :)

> Ну, не будут... Чем раньше появится, тем быстрее вылечится... А так не
> понятно что и где чинить. К тому же пока я буду обновлять одну часть,
> другие обновятся... Работать-то всё не перестанет...
работать тоже перестанет, но вне репозитория. То есть если какой-то
пакет позволяет писать пользовательские скрипты, то может получиться,
что 2х модулей от которых зависит такой скрипт нет ни в новом, ни в
старом питоне.

>>> Вот только, перечитывая, python policy, я не заметил описания по
>>> правильной сборке самих питонов.
>> Ну мы их планировали собирать сами, и как-то не думали это писать... а
>> вообще этот документ устарел уже очень давно, я никак не могу понять,
>> почему его никто не хочет переписать и убрать с него
>> авторство cray@/morozov@/ns �� ...
>
> Историю не выкинешь... ;)

эээ... тут как бы ситуация проблемна в том что, Python Policy было
наверное первым. Мы прошли кучу грабель, которых смогли избежать
остальные, но это самое полиси уже давно и безбожно устарело.

rpm-build-python переписывался и правился уже не один раз, а полиси
никто не правит.

Так что теперь некоторые описанные в нём вещи вообще не работают, а
виноватыми почему-то остаются изначальные авторы! :(

>>> Про модули есть, про зависимости
>>> понятно, а про питоны, как бы, всё и так ясно и подробно не
>>> расписано... Я понимаю процесс так. Делаем python-2.6.2 и
>>> python25-2.5.4, а дальше собираем, что можем...
>> я бы попросил python2.5-2.5.4, то есть с точкой в имени...
>>
>
> Ну, ok... Я пропустил этот момент из полиси, там в разных контекстах
> по разному пишется... Я ведь специально сверял, а всё равно ошибся...
> ;)
Ну собсно это там насколько я помню совсем уж чётко не прописано.(с
кляузой SHOULD :) ), а без точки оно там кажить только для --with у rpm,
ибо точка там не жуётся :(

>>> Поскольку оба варианта имеют недостатки, думаю, что можно попытаться
>>> собрать большой shared task с максимальным числом пакетов, которые
>>> получится пересобрать, а для остальных сделать compat...
>> я бы постарался избежать второй части...
>>
>
> Я не представляю себе как, за фиксированный промежуток времени это
> осуществить вручную... Других механизмов я не знаю, кроме как ssh
> git.alt task XXX add repo.
Выкинуть неперсобранные за неделю/месяц/год пакеты из репозитория...

> 2) Как задать правильный порядок пересборки для выбраннной массы
> пакетов.
Отсортировать по алфавиту, а потом собирать весь набор до тех пор, пока
выходной набор не перестанет меняться... да, я знаю, что это brute-force
:)

А так, в качестве простейшей оптимизации конечно стоит для начала
собирать архитектурно-зависимые пакеты.
----------- ��������� ����� -----------
���� ������� �������� �� � ��������� �������...
���     : �����������
���     : application/pgp-signature
������  : 196 ������
��������: �����������
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20090715/2cca6521/attachment.bin>