Re: [devel] RPM: including additional docs

From: Ivan Zakharyaschev <vanyaz@mccme.ru>
To: <devel@linux.iplabs.ru>
Subject: Re: [devel] RPM: including additional docs
Date: Sat, 25 Nov 2000 13:04:49 +0300 (MSK)
Message-ID: <Pine.LNX.4.30L.0011251221040.902-100000@zephyrous.ru> (raw)
In-Reply-To: <20001124010924.A1348@localhost.localdomain>

	Hello!

On Fri, 24 Nov 2000, Mikhail Zabaluev wrote:

> Для начала предложу выделить эту отдельную документацию в отдельный
> пакет
> - чтобы строить как noarch независимо от основного пакета, и, поскольку
> исходные файлы распространяются отдельно, иметь меньше проблем с
> версиями
> и релизами. Я сделал так с php-manual и нисколько не жалею.

В этом случае получилось. Но можно придумать иакую ситуацию, где:

1. нужно в главный пакет включить дополнительную документацию, которая не
из исходников программы (например, README.ipl).

2. Что-то из документационных файлов, входящих в состав распространяемых
исходников, хочется исклюить из основного пакета и включить во
вспомогательный doc.

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

> А касательно файлов, на мой взгляд, техника проста: размещаем их в том
> виде, в котором они попадут в %_docdir (т.е. архивы распаковываем,
> другие
> файлы - копируем), там, где rpm их будет искать по умолчанию -
> в $RPM_BUILD_DIR/%{name}-%{version}. Ну или сами укажите где, с помощью
> %setup -T -n <имя>
> Секции %build и %install можно опустить. Затем перечисляем в %files с
> директивой %doc - и файлы попадают куда надо.

Ну да -- это все удобно в отдельном пакете. И, по-моему, такой способ как
раз является правильным с точки зрения концепций RPM. Что
именно тут удобно? То, что документация готовится к установке в отдельном
файловом пространстве ($RPM_BUILD_DIR). Остальые свойства такой сборки не
так уж важны: то, что создается отдельгый пакет. Как я уже сказал, может
быть нужно распределить эту документацию по разным пакетам. Так вот: чтобы
это удобное свойство подготовки документации в отдельном файловом
пространстве, присущее сборке отдельного пакета, совместить с возможностью
перераспределения документации по подпакетам, я предлагаю в
одном spec-файле использовать параллельные процедуры подготовки/сборки для
независимых модулей исходников. Результаты этих параллельных процедур
потом объединялись бы на стадии %install в единое дерево.

На самом деле директива %doc определяет несколько стадий сборки пакета.
Это можно увидеть, если посмотреть на логи RPM при создании пакета.
Во-первых, %doc relative_path/file задает стадию, параллельную %install,
которая занимется тем же, что и %install: устанавливает указанные файлы
документации в $RPM_BUILD_ROOT из $RPM_BUILD_DIR. (Эта стадия исполняется
после %install при вызове rpm -bi.)

Во-вторых, %doc relative_path/file дополняет список файлов %files. Это
явная часть ее работы, которая видна из устройства spec-файла.
Естественно, при включении указанных файлов в пакет она ставит им нужные
атрибуты (что это документация). При выполнении этой работы %doc уже
основывается на путях к уже установленным в $RPM_BUILD_ROOT файлах.

В случае %doc absolute_path/file первая часть работы %doc пропускается.

Итак, параллельные стадии сборки пакета уже неявно присутсвуют в RPM: это
%install и %doc (ее install-часть). Создание нескольких пакетов на
последней стадии тоже может рассматриваться как несколько параллельных
стадий работы RPM в режиме сборки.

-- 
Best regards,
      Ivan Z.

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