В помощь мэйнтейнеру - spec-cleaner и rediff patch

Материал из Rosalab Wiki
Перейти к: навигация, поиск

Работа мэйнтейнера включает в себя много рутинных операций — адаптацию spec-файлов под изменяющиеся политики и инструменты сборки, переделку патчей под новые версии пакетов, обновление списка файлов приложения в пакете и так далее. Много рутины берет на себя инструментарий сборки — сам rpmbuild и вспомогательные скрипты из пакета spec-helper. Однако эти скрипты по определению не могут выполнить ряд задач — например те, которые требуют внесения изменений в spec-файлы.

Чтобы несколько облегчить жизнь мэйнтейнеров, мы включили в пакет spec-helper два новых скрипта, которые не применяются автоматически при сборке, а предназначены для ручного запуска человеком. Полагаю, названия скриптов говорят сами за себя — spec-cleaner и rediff_patch. Обновите в своей системе spec-helper, и эти скрипты появятся у вас в /usr/bin.

Spec-cleaner выполняет следующие действия:

  • удаляет устаревшие и ненужные декларации — например, определение BuildRoot и Packager, зависимость от install-info, очистку buildroot и так далее;
  • изменяет оформление использования макросов и переменных — переменные печатаются в фигурных скобках — %{const}, а макросы — без них — %{macro}. Такие изменения производятся только для макросов и переменных, определенных в самом rpm (а точнее, перечисленных непосредственно в скрипте spec-cleaner). Если вы сами определяете какие-то сущности, то их оформление скрипт изменять не будет;
  • изменяет форматирование Summary — делает первую букву заглавной, удаляет точку в конце;
  • удаляет явные определения переменных %{name}, %{version} и %{release};
  • заменяет устаревшие макросы на современные аналоги;
  • … и много других мелочей.

Пользоваться spec-cleaner — проще простого:

spec-cleaner my.spec

Если вы не хотите, чтобы изменения делались непосредственно в spec-файле, то можно указать второй параметр — имя нового spec-файла:

spec-cleaner old.spec new.spec

При разработке spec-cleaner мы старались прежде всего избежать ситуаций, когда новый spec-файл окажется некорректным — поэтому некоторые недочеты spec-файлов, исправление которых кажутся тривиальными, пока не реализованы.


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

  1. запускать rediff_patch необходимо в директории склонированного проекта — там, где лежит spec-файл и патчи. Spec-файл используется для того, чтобы определить — как именно применяется патч;
  2. в эту же директорию необходимо поместить новый тарболл с исходным кодом, для которого надо переделать патч;
  3. непосредственно запуск скрипта выглядит так:
 rediff_patch <patch_ro_rediff> <tarball>

Если у вас в директории только один тарболл, то второй параметр можно опустить — rediff_patch возьмет единственный тарболл самостоятельно.

В ходе работы rediff_patch создаст директорию rediff_patch, распакует в нее новый тарболл и попытается применить к нему патч с параметрами, взятыми из spec-файла, добавив к ним опцию «--force» и используя значение fuzz по умолчанию (при сборке в rpmbuild используется «--fuzz=0»). Сейчас скрипт рассчитан на работу с тарболлами, при распаковке которых получается одна директория — обрабатывать tar-бомбы он откажется. В случае, если все сложится успешно, рядом с вашим патчем вы обнаружите новый патч с суффиксом «.new», а остальные следы деятельности скрипта (директория rediff_patch со всем содержимым) будут уничтожены. Если же что-то не заладится (например, патч применился не целиком), то вам останется директория rediff_patch с двумя поддиректориями — исходной и новой, к которой пробовали применить патч. Так что вы сможете вручную завершить работу, которую не получилось сделать автоматически, и уже самостоятельно сформировать новый патч с помощью стандартного diff -Naur.

Практика показывает, что большинство патчей все-таки требуют доработки, переделать их автоматически с использованием --force и более мягкого значения fuzz получается не очень часто. Однако даже если rediff_patch справился со всем самостоятельно, обязательно проверьте результирующий патч — ведь '--force' иногда может привести к нежелательному результату. А если rediff_patch не справился — что ж, по крайней мере, мы немного сэкономим на распаковке архива и первой попытке применить патч.

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

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.