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

[Igor Vlasenko]

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

Вступление.

У  нас в ALT Linux Team полностью автоматизированы подготовка chroot и сборка пакетов в chroot (hasher) и приемка пакетов в репозиторий (incoming). Долгое время оставалась не занятой ниша подготовки исходных пакетов, которую теперь постепенно заполняют разрабатываемые решения по автоматизации.
Хотел бы обрисовать, какая там ситуация.

Представим эти решения в виде стека решений по уровням абстракции.
Первый уровень - язык манипуляций с исходным пакетом.
Второй уровень - утилиты манипуляций с исходным пакетом.
Третий уровень - утилиты обработки репозитория.
Четвертый уровень - автономные сборочные ноды.
Пятый уровень - агрегаторы автономных сборочных нод.

Итак.

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

RPM spec файл - это достаточно специфический формат, и стандартными утилитами для работы с текстом с ним работать неудобно, так как, как правило, изменения должны быть локализованы в отдельной секции RPM spec файла, что не так просто добиться с sed или awk. С другой стороны, создавать полностью оригинальный специализированный язык обработки спек-файлов, наподобие xslt для xml, выглядит несоразмерным задаче.
Оказалось удобным подходом расширить возможности существующего языка программирования с помощью специализированной библиотеки для работы исходными RPM пакетами и RPM spec файлами, получив таким образом язык манипуляций с исходным пакетом, сочетающий удобство знакомого языка программирования и мощь специализированного языка для предметной области.
Для разработки текущего стека приложений автоматизации был выбран язык программирования perl и под него создана библиотека манипуляций спек-файлом RPM::Source::Editor.
Некоторым неудобством такого подхода является тот факт, что поскольку сейчас нет общепринятого языка быстрого прототипирования, то различным людям могут быть удобны разные языки, и этим удобным языком не обязательно окажется perl. Это в перспективе создает потенциальный барьер и препятствия для мотивации к изучению и использованию средств автоматизации другими людьми.
Сейчас спасает ситуацию то, что язык манипуляций с исходным пакетом требуется в основном для собственно разработки утилит, а уже при повседневной работе с утилитами можно и обойтись без использования  языка манипуляций с исходным пакетом, просто внося при необходимости нужные изменения руками.
На уровне утилит эти детали реализации (perl и т. д.) уже скрыты. В перспективе можно пойти еще дальше  портировать  библиотеку манипуляций спек-файлом под python и, возможно, еще под несколько языков программирования, и добавить в утилиты обработки исходных пакетов поддержку пользовательских скриптов на разных языках программирования, облегчив, таким образом, жизнь пользователям утилит автоматизации с разными предпочтениями.
Пример использования  языка манипуляций с исходным пакетом. Допустим, есть много пакетов с библиотеками, удоволетворяющих SharedLibs Policy, для которых возникает необходимость выпускать compat-библиотеку. Если эта необходимость возникает  достаточно часто, процесс создания compat-библиотеки можно автоматизировать.
Пустой шаблон для пользовательского кода на perl имеет вид:

push @SPECHOOKS, 
sub {
    my ($spec, $parent) = @_;
};
Создадим на его основе пользовательскую программу, создающего из пакета с разделяемой библиотекой compat-библиотеку, файл mk_compat_sharedlib.pl
Впишем туда код для создания compat-пакета:
push @SPECHOOKS, 
sub {
  my ($spec, $parent) = @_;
  $spec->set_default_changelog('- compat release');
  # сюда запомним основу имени пакета с библиотекой
  my $newname;
  # проходим по всем секциям спек-файла
  foreach my $section ($spec->get_sections) {
	# нас интересуют только секции %files
	next if $section->get_type ne 'files';
	my $package_name=$section->get_package_name;
	# если подпакет с библиотекой (вида lib%name%soname)
	if ($package_name =~ /^lib(.*\d)$/) {
		$libbase=$1;
		$section->set_tag('Group','System/Legacy libraries');
	# удаляем -devel* пакеты, docs и утилиты, кроме разве плагинов,
	# так как они будут конфликтовать с основным пакетом
	} elsif ($package_name=~/-devel/ or not $package_name=~/-plugin/) {
		$section->delete();
	}
  }
  # предохранимся
  die "Oops! Lib section not found" unless $newname;
  # проверим, надо ли переименовать сам src.rpm
  my $name = $spec->main_section->get_tag('Name');
  if ($name !~ '/\d$/) { # не оканчивается на цифру -будет конфликтовать
	$spec->rename_main_package($newname);
  }
};

Применить этот код можно к спек-файлу
srpmtool --hook mk_compat_sharedlib.pl  -i /path/to/.spec
или сразу создать готовый новый compat src.rpm:
srpmtool --nextrel incr --hook mk_compat_sharedlib.pl /path/to/src.rpm
(здесь --nextrel incr увеличит у получившегося src.rpm релиз на 1 и добавит запись в %changelog)

если mk_compat_sharedlib.pl уже готов и под рукой,
то создание compat библиотеки займет доли секунды
вместо нескольких минут при работе вручную.

Если же пакеты нужно обрабатывать сотнями или тысячами,
то альтернатив автоматизации просто нет.

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

-- 

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.