[devel] Python-2.6

[Evgeny Sinelnikov]

15 июля 2009 г. 1:30 пользователь Ivan Fedorov (ns at altlinux.org) написал:
> Evgeny Sinelnikov <sin-u2l5PoMzF/Uox3rIn2DAYQ at public.gmane.org> writes:
>
>> 15 июля 2009 г. 0:23 пользователь Andrey Rahmatullin (wrar at altlinux.ru) написал:
>>> On Wed, Jul 15, 2009 at 03:19:32AM +0700, Michael Pozhidaev wrote:
>>>> Надо только отправить на пересборку или сидеть править что-нибудь
>>>> придётся?
>>> Ну теоретически что-то может быть несовместимо, но в идеале просто
>>> пересобрать.
>>>
>>
>> Ну, теория нам уже не поможет, потому что зависимости скажут rpm'у,
>> что никакой совместимости нет и всё перестанет устанавливаться... Но
>> сейчас этого girar-builder не позволит.. Хотя... может и позволит...
>>
>> Значит так... Вариантов переезда два... Первый... И второй... ;)
>>
>> Первый - это mass rebuild и зависит как бы не то меня... Обычно это
>> делалось в недрах. Но сейчас стало ближе к простому народу. Теперь я
>> делаю shared task и призываю дать мне mass nmu и начинаю
>> пересобирать... Дело это достойное, но уж слишком трудоёмкое...
> угу, но это "правильный" путь.

Без автоматизации путь, каждый раз, одинаково сложный... А у меня
такого автомата пока нет. Тут нужна ручка, чтобы попробовать
пересобрать и увидеть, что отвалилось. Для такой пересборки неплохо бы
уметь учитывать зависимости в обратном порядке... Хотя от циклических
зависимостей это не избавляет, но это можно обойти путём кеширования
ручных поправок, которые для заданного репозитория буду сохраняться
достаточно долго...

Я тут что-то непонятное придумал, а ведь всё уже как-то работает, так
что, с моей стороны, это только домыслы...Этот инструментарий уже,
скорее всего, есть. Только не описан и,вероятно, не опубликован, в
силу постоянной переделки и незавершённости...

Мы как-то прорабатывали механизмы написания такого инструментария на
питоне, но python-module-apt у нас безнадёжно сломан... Общий код не
приведён в нормальную библиотеку и всё время "катэндпастится" между
разными частями... Но это тема совсем другого разговора, который я
как-нибудь ещё подниму...

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

Ну, ужас... Но ведь не ужас, ужас, ужас... :)

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

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

Историю не выкинешь... ;)

>> Про модули есть, про зависимости
>> понятно, а про питоны, как бы, всё и так ясно и подробно не
>> расписано... Я понимаю процесс так. Делаем python-2.6.2 и
>> python25-2.5.4, а дальше собираем, что можем...
> я бы попросил python2.5-2.5.4, то есть с точкой в имени...
>

Ну, ok... Я пропустил этот момент из полиси, там в разных контекстах
по разному пишется... Я ведь специально сверял, а всё равно ошибся...
;)

>> Поскольку оба варианта имеют недостатки, думаю, что можно попытаться
>> собрать большой shared task с максимальным числом пакетов, которые
>> получится пересобрать, а для остальных сделать compat...
> я бы постарался избежать второй части...
>

Я не представляю себе как, за фиксированный промежуток времени это
осуществить вручную... Других механизмов я не знаю, кроме как ssh
git.alt task XXX add repo. А при таком числе пакетов, только на
установленной системе, как:
$ rpm -e python-base --test 2>&1|wc
    553    2240   37623
я не представляю себе это сделать, я представляю это как закат солнца
вручную... Но ведь это уже до меня делалось и причём неоднократно...

>> Прошу высказать пожелания и возражения...
> Попытаться в очередной раз внедрить MassNMU Policy...

Здесь нужна не только политика, но и механизмы... Я точно не
представляю себе как:
1) узнать точный список пакетов для пересборки. Оценить можно так:
$ apt-cache whatdepends python-base|cut -d " " -f3|grep "^[^ ]"|wc
    922     922   27589
Но это оценка, причём грубая, причём без учёта зависимостей и для
бинарных пакетов, а нужно узнать число исходных.

2) Как задать правильный порядок пересборки для выбраннной массы пакетов.

-- 
Sin (Sinelnikov Evgeny)