[devel] I: arepo: next steps

[Igor Vlasenko]

Уважаемые коллеги,

В общем, так понимаю, arepo стагнировал, а это вещь нужная.
Решил, раз нет возражений, заняться arepo плотнее.

Что уже сделано:
подготовил патчи к arepo, добавляющие 
1) поддержку репозиториев без noarch компоненты (по просьбе Сергея)
2) модульный конфиг-файл для arepo, c директивой "include: |"
Отличие от прототипа в том, что поменял тип строки yaml c '>' на '|',
т.е. есть возможность задать пути с пробелами внутри.

include: |
   /home/vpupkin/Рабочий Стол/NX-client-arepo-t6.conf

Повесил заявку 
http://bugzilla.altlinux.org/show_bug.cgi?id=26985
надеюсь, эти изменения скоро будут в Сизифе.

Что хочу сделать:

I. распрямить работу arepo с apt.

arepo сейчас, чтобы узнать EPOCH-VERSION-RELEASE пакета NAME,
создает aptbox и выполняет
 apt-get install --yes --print-uris NAME
Если apt-get install завершился успешно, получаем путь к rpm
файлу в локальной файловой системе, затем открываем полученный
rpm файл с помощью python-rpm и извлекаем значения из RPM Header'а.

Это и слишком медленный путь, и слишком глючный.

Симптомы глюка:
В t6 обновился libpng12. Ожидалось, что arepo пересоберет
i586-libpng12. Однако arepo пересобрал не только i586-libpng12,
но и около 30 других пакетов, именно все имевшиеся зависящие от
i586-libpng12 пакеты, включая wine, поскольку из-за несоответствия
версий libpng12 и i586-libpng12 они оказались не устанавливаемыми 
и apt-get install --yes --print-uris завершался для них неуспешно.

Я хочу переделать этот кусок, чтобы напрямую брать данные из кеша apt.
В результате и ускорится холостой пробег arepo, и больше не будет
таких глюков, и появится возможность работать с сетевыми репозиториями.

II. вырезать из arepo.py низкоуровневую работу с rpm в отдельный
скрипт.

Собственно arepo.py пусть и дальше занимается тем, чем и занимался,
т.е. созданием и обновлением x86_32 репозитория,
а отдельный скрипт araperpm, rpm2arepo или как его назвать.py
будет заниматься конкретно созданием 
i586-name-V-R.src.rpm из name-V-R.i586.rpm.

Это не повлияет на производительность, так как специфика питона -
что любой скрипт легко выступает в роли библиотеки.
И arepo будет просто загружать rpm2arepo.py как свою библиотеку.

Это и существенно упростит отладку, и, главное, встраивать в
сборочницу весь arepo смысла не имеет, сборочнице нужна только
функциональность rpm2arepo.py. Все остальное - сборка пакетов
и менеджмент репозиториев - в сборочнице уже есть, имеющаяся
высокоуровневая часть arepo - это по сути дублирование скриптов сборчницы,
но не полное, недостаточного качества и написанное на python.

Мое предложение -- arepo надо разрезать на две части 
и встраивать в сборчницу сразу низкоуровневый скрипт конверсии rpm,
условное название rpm2arepo.py.


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine