[devel] RPM: including additional docs

[Ivan Zakharyaschev <vanyaz@mccme.ru>]

	Добрый вечер!

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

Проблема: в пакет включается дополнительная документация, которая берется
из отдельных файлов (они указаны как SourceX). Эти файлы могут
представлять из себя как архивы, так и просто файлы, включаемые в пакет
почти без изменений. Проблема в том, на какой стадии сборки пакета их
разархивировать (если это архив) и как (какой директивой) включать в пакет
на заключительном этапе (%files, %doc).

Первая часть проблемы: разархивация.

Варианты для архивов:

A1) разархивировать на стадии %prep вместе с основными исходниками в то
файловое пространство, где будет происходить build самой программы (с
помощью %setup, например);

A2) разахивировать на стадии %install, поместив извлеченные файлы опять в
то же самое файловое пространство, где произошел build программы -- туда
же, куда разархивировал бы и %setup);

A3) разархивировать на стадии %install сразу в то дерево, куда
устанавливаются готовые файлы на этой стадии ($RPM_BUILD_ROOT).

Все те же варианты есть и для отдельных файлов, не требующих разархивации:
действие разархивации надо заменить на копирование.

По конечному результату первые два варианта не отличаются: все равно эта
дополнительная документация не участвует в компиляции программы. Аргументы
в пользу первого варианта: удобство использования %setup для распаковки
(для отдельных файлов это не так); в пользу второго: после внесения
изменений в эту документацию (особенно актуально для отдельных
файлов-описаний от упаковщика типа README.ipl) не придется заново
проходить через долгую стадию %build для создания пакета, достаточно
будет выполнить rpm -bi --short-circuit. (Для нормальных программ
повторное исполнение %build, конечно, не должно быть проблемой, но все
же.) Аргументы против второго способа: такое действие (копирование данных
из SOURCES в BUILD) не совпадает с направлением остального потока данных
на этой стадии: %install ставит файлы из BUILD в $RPM_BUILD_ROOT.


Вторая часть проблемы: как включать файлы дополнительной документации в
пакет?

Мне известно три способа включения документации в пакет:

B1) директивой вида %doc filename, где filename задано относительно корня
дерева, в котором была произведена компиляция. При ее исполнении заданный
файл копируется в нужную директорию (обычно %{_docdir}/%{name}-.../)
внутрь создаваемого пакета;

B2) директивой вида %doc path, где path - путь ко включаемому файлу в
$RPM_BUILD_ROOT; файл предварительно должен быть установлен туда на стадии
%install (в предыдущем варианте этого не требвалось);

B3) указанием нужного файла среди остальных %files с предварительной его
установкой на стадии %install и указание директивой %docdir того, что
директория, в которую он ставится, содержит документацию (заранее уже
известен набор стандартных таких директорий; man-pages и info так и
ставятся).

Способ B1 может быть использован в сочетании со способами разархивации в
пространство компиляции A1 и A2, а остальные два B2 и B3 - в сочетании с
A3. Недостаток последнего варианта мне видится в том, что не очень легко
на стадии %install составить путь к месту расположения документации:
например, если мы решим переразбить документацию между пакетами и включить
эту документацию не в главный пакет, а в подпакет, то это уже не будет
%{_docdir}/%{name}-%{version}/ и придется вносить изменения не только в
%files, но и в %install (что не очень удобно: для файлов другого типа мы
бы просто перенесли их указание из одного раздела %files в другой). По
сути, для документации, попадающей в стандартное место (это не так для
man-pages), в случаях B2 и B3 мы совершаем лишнее действие: %doc умеет
сама помещать файлы, куда надо, зачем нам еще раз думать об этом при
написании %install?

Раз %install - лишнее действие, его можно было бы перепрыгнуть. И что
тогда получаем? - Прямое копирование документации из SOURCES в создаваемый
пакет. rpm этого не умеет, но можно было бы сделать %doc еще более
запутанным и добавить к его возможностям и такое, например

%doc -s 3

включало бы в пакет в качестве документации Source3 (в разархивированном
виде, если надо); %doc стала бы чем-то похожа на %setup.


Но: может потребоваться немного переработать эти дополнительные файлы
докумениации во время сборки пакета на основании информации, неизвестной
заранее (%packager, например), которую нельзя статически включить в
исходники. Для этого сокращенный вариант %doc, включающей файлы сразу из
SOURCES, не подойдет. Итак, опять возвращаемся к тому, что имеем два
этапа, через которые должна пройти эта документация, на каждом из них по
три варианта. Новое требование -- возможность ее динамически менять --
ничего в отношении этих способов не меняет: те же преимущества и
недостатки. Теперь только между этими двумя этапами надо включить еще и
переработку файлов. Чтобы сохранить преимущества всех вариантов и убрать
все их недостатки, можно было бы использовать во время сборки пакета еще
одно независимое файловое пространство (наряду с SOURCES, местом
компиляции и $RPM_BUILD_ROOT) для подготовки дополнительной документации.
Операции в нем совершались бы на двух специальных стадиях: %prepdoc и
%builddoc. %prepdoc аналогична %prep, позволяет использовать %setup для
разархивации документации. %builddoc вносит динамические изменения.
(Для полной аналогии можно сделать %installdoc для установки файлов из
нового специального файлового пространтсва в $RPM_BUILD_ROOT: может
понадобиться для включения в пакет info- и man-pages из отдельных
источников.) %prepdoc и %buildoc, естественно, могут быть выполнены
независимо от основных %prep и %build, поэтому изменение в дополнительной
документации не потребует перекомпиляции программы.

После %install остается единый $RPM_BUILD_ROOT, из которого берутся файлы,
перечисленные в %files, и отдельные файловые пространства, где происходила
компиляция программы и где подготавливалась отдельная документация. %doc
тогда могла бы принимать в качестве аргументов файлы из того и из другого
пространства (различие делалось бы по какой-нибудь опции).

Чем так будет лучше? Пока самый приемлемый вариант работы с дополнительной
документацией это A2-B1 (разархивация в место компиляции на стадии
%install и включение в пакет директивой %doc), но он концептуально
неправильный: во-первых, в %install происходит установка файлов в другом
направлении, во-вторых, включение в раздел %install команд для переработки
документации портит его наглядность (потому что такие действия там не
предполагаются).


Такие изменения могут показаться несоизмеримыми с решаемой пустяковой
проблемой. Но, по-моему, эти изменения в моделе сборки пакетов могут быть
развиты и могут предоставить новые интересные возможности при сборке
пакетов, способствовать большей ясности spec-файлов, что, наверное,
немаловажно при возрастающем количестве пакетов.

Если я где-то непонятно выразился, готов давать пояснения. Будут еще
другие идеи, связанные с другими проблемами.

-- 
Best regards,
      Ivan Z.


_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel