[devel] I: embedded language for src.rpm/spec file editing (part I).

[devel] I: embedded language for src.rpm/spec file editing (part I).

[Igor Vlasenko]

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

------------------------------------------------------
Утилиты для манипуляции spec-файлами и src.rpm пакетами.

Введение во встроенный язык редактирования spec-файлов и src.rpm пакетов.

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

Эта стратегия была использована при создании различных
утилит для манипуляции spec-файлами и src.rpm пакетами,
таких как srpmnmu, srpmbackport, srpmconvert,
набора утилит для массовых операций с пакетами girar-nmu,
утилит repocop-nmu, автономных сервисов, таких как cronbuild, 
croncopy, cronbackports, autoports, fedoraimport и других.

В основе этих программ лежит библиотека perl-RPM-Source-Editor.
Это библиотека perl, и при желании с ней можно работать как с любым
другим perl'овым модулем. Однако все вышеперечисленные программы
позволяют "на лету" изменять и дополнять свое поведение, подгружая с
помощью опций --hook куски кода на perl, в котором можно напрямую
работать с уже готовым инициализированным объектом, соответствующим
spec-файлу или src.rpm пакету. 

Поэтому не зря этот текст и назван введением во встроенный язык
редактирования spec-файлов и src.rpm пакетов.

На кого рассчитано это введение? На всех, кто сопровождает более 
десятка пакетов.
Мы же free people using free software, нам не пристало бесконечно
повторять руками монотонные операции, когда возможен unix-way:
пишем небольшой скрипт и за 5 минут обрабатываем все 100 своих пакетов
или вообще все 12.000 пакетов Сизифа.

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

==Утилиты.==

Сначала познакомимся, как пользоваться вышеупомянутыми утилитами,
поскольку загружаемые через --hook расширения работают не
самостоятельно, а с помощью этих утилит.

Утилиты выполняют начальную распаковку src.rpm пакета,
чтение spec-файла, инициализируют необходимые объекты, выполняют свои
действия и код, указанный пользователем в опциях --hook, и записывают 
новый измененный src.srm либо spec-файл.

Эти утилиты обладают достаточно богатой встроенной функциональностью,
и разделяют ряд общих опций, унаследованных от модуля RPM::Source::Transform.
Рассмотрим их на примере утилит srpmnmu и srpmtool.

Вызов srpmnmu:
 srpmnmu --changelog '- Yes! We can!' /path/to/foo-<oldversion>-alt<release>.src.rpm
или
 srpmnmu --changelog '- Yes! We can!' -i foo.spec

Опция --changelog может быть сокращена до --ch, а в некоторых утилитах --- 
и до -c.

Действие srpmnmu по умолчанию - инкрементировать релиз в соответствии
со политикой nmuadd (добавить .1 к релизу, если нет точки в релизе;
иначе увеличить число после точки; примеры: alt2 -> alt2.1, alt2.1 ->
 alt2.2 и т.д.) и добавить changelog.

Есть и другие политики увеличения релиза, которые выбираются опцией
--next-release-policy (также, --nextrel). Например,
 srpmnmu --nextrel=incr -- обычное увеличение релиза (alt2 -> alt3 и т.д.)
 srpmnmu --nextrel=nmuappend -- "классический" nmu c расческой из единиц 
(alt2.1 -> alt2.1.1, alt2.1.1 -> alt2.1.1.1 и т.д.)
Отключается увеличение релиза
 srpmnmu --nextrel=none (это то же самое, что вызвать srpmtool;
 srpmtool -- это srpmnmu с политикой увеличения релиза none по умолчанию.

Можно явно указать Release: 
 srpmnmu --release alt1.rc4_final

Можно явно указать Version: 
 srpmnmu --version <newversion>
При этом, если "<newversion>" > "<oldversion>", то релиз, если не
 указан, будет сброшен в alt1. Если же у нас downgrade, 
"<newversion>" < "<oldversion>", то, если другое не указано, будет
 увеличен и Serial, и Release (В присутствии Provides/Obsoletes это
 наиболее разумное поведение).

Явно указать Serial: можно опциями --serial и --epoch, в зависимости
от того, какой тег мы хотим получить в spec-файле.

С опцией --version, если редактируется src.rpm, а не spec-файл, обычно
нужно еще указать архив исходных текстов новой версии. Т.е. набор
опций для обновления src.rpm пакета до новой версии выглядит так:
 srpmnmu --version <newversion> --copy_to_sources=foo-<newversion>.tar.gz /path/to/foo-<oldversion>-alt<release>.src.rpm
(Здесь без разницы,  srpmnmu или  srpmtool.)

Для библиотеки вместе с обновлением исходных текстов до новой версии
можно выпустить и compat-версию:

 srpmnmu --rename foo4 \
   --changelog '- compat library' \
   --group-translate 'Development/C|System/Legacy libraries,Development/C++|System/Legacy libraries' \
   /path/to/foo-<oldversion>-alt<release>.src.rpm

Есть еще опция --uupdate, автоматически обновляющая src.rpm,
содержащий .watch файл, --group-translate, меняющая группы rpm, и
много других.

Однако, понятно, что каким бы богатым не был бы набор опций, он не в
состоянии покрыть всю имеющуюся функциональность.

Здесь на помощь приходит встроенный язык.

Продолжение в части II:
Программирование на языке манипуляций spec-файлом.


-- 

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.