[devel] Стек решений автоматизации. lvl.2

[Igor Vlasenko]

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

проолжаю рассказ про автоматизацию.

Второй уровень — утилиты манипуляций с исходным пакетом.

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

<утилита> --hook <процедура1> --hook <процедура2> ... --hook <процедураN>

За время разработки накопилось достаточно много разных утилит, утилиты repocop, утилиты girar-nmu, много разных типов утилит импорта, преобразования и создания пакетов.  Все эти утилиты основаны на общей архитектуре, устроенной по принципу конструктора ЛЕГО: если нужна какая-то функциональность, то достаточно внутри кода утилиты просто подключить соответствующий модуль командой 
use <Имя модуля>;
типичный набор модулей можно получить, используя

use RPM::Source::Transformation::GenericUtility;

Что дает «из коробки» достаточно богатую функциональность для самых простых утилит. Например, рассмотрим утилиту srpmbackport. Базовая функциональность этой утилиты аналогична утилите rpmbph из пакета etersoft-build-utils: 

~ $ srpmbackport -M60T arduino-1.0.1-alt1_1jpp7.src.rpm
Записан: ./arduino-1.0.1-alt1_1jpp6.M60T.1.src.rpm

Но что, если эта версия arduino слишком свежая, и мы не хотим замещать ей старую версию 0022 в t6? Используем опцию --rename, чтобы отправить эту версию как другой пакет:

 ~ $ srpmbackport -M60T --rename arduino1 arduino-1.0.1-alt1_1jpp7.src.rpm
Записан: ./arduino1-1.0.1-alt1_1jpp6.M60T.1.src.rpm

Если же нужно отправить пакет в бранч 5.1, то необходимо будет еще исправить группу, так как в том rpm, что в  бранче 5.1, группы  Engineering еще  нет:

 ~ $ srpmbackport -M51 --rename arduino1 arduino-1.0.1-alt1_1jpp7.src.rpm --group-translate 'Engineering|Development/Other'
Записан: ./arduino1-1.0.1-alt1_1jpp6.M51.1.src.rpm

Заметим, что здесь нам пришлось указывать через опцию --group-translate 'Engineering|Development/Other' нужное нам преобразование групп вручную. утилита autoportsmass применила бы к этому пакету при портировании подобное преобразование групп, и еще ряд полезных преобразований, автоматически. 

Заметим, что утилита autoportsmass применила бы при портировании  подобное преобразование групп автоматически. Утилита autoportsmass, принадлежащая в нашей классификации к третьему уровеню — утилитам обработки репозитория — обладает функциональностью более высокой абстракции над утилитой srpmbackport, принадлежащей в нашей классификации ко второму уровню — утилитам обработки пакета. А на четвертом уровне —  уровне автономных сборочных нод — аналогом утилиты srpmbackport является автономная сборочная нода autoports.altlinux.org.

В качестве другого примера можно назвать опцию --refresh-timestamp.

команда
srpmtool --refresh-timestamp -i spec 
или
srpmtool --refresh-timestamp /path/to/srpm 

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

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

В базовой комплектации srpmtool более 40 опций. Эти же опции есть и у srpmnmu, и у srpmbackport, и у целого ряда других утилит. 

Исторически утилиты работы с пакетами были менее унифицированы. Это приводило к сложности повторного использования кода и к дополнительным затратам на поддержку. В особенности необходимость более тесного взаимодействия с repocop в процессе импорта пакетов привела к необходимости разработки новой полностью компонентной архитектуры.

В этой новой архитектуре утилита представляет собой контейнер компонент.  Компонента может иметь собственные опции командной строки и обмениваться сообщениями с другими компонентами. 

Обработка исходных пакетов происходит следующим образом:
Очередной исходный пакет (спек-файл или src.rpm файл) передается на вход каждой компоненте. В ответ компонента создает и возвращает объект(ы) Transformation (преобразования сходного пакета).

Объекты Transformation накапливаются и сортируются по приоритету выполнения в специализированной коллекции. В итоге полученная коллекция передается обьекту Player. В стандартном плеере преобразований преобразования просто применяются и затем генерируется новый измененный  спек-файл или src.rpm файл. Есть и другие плееры, например, используемые в repocop, которые генерируют вместо измененного исходного пакета патч к спек-файлу или куммулятивный патч, где результат каждого преобразования выполнен в виде отдельного подпатча (полезно, когда хочется узнать, какой именно тест repocop отвечает за то или иное сгенерирорванное изменение).

Как итог, легко создавать самые разнообразные утилиты. Загружаем нужный набор компонент, меняем настройки по умолчанию, добавляем немного уникального кода и получается совсем другая утилита.

В настоящее время завершается перевод всех утилит на новую компонентную архитектуру.

-- 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.