[devel] RPM: including additional docs

[Mikhail Zabaluev]

Hello Ivan,

On Sat, Nov 25, 2000 at 13:04 +0300, Ivan Zakharyaschev wrote:
>
> 	Hello!
> 
> On Fri, 24 Nov 2000, Mikhail Zabaluev wrote:
> 
> > Для начала предложу выделить эту отдельную документацию в отдельный
> > пакет
> > - чтобы строить как noarch независимо от основного пакета, и, поскольку
> > исходные файлы распространяются отдельно, иметь меньше проблем с
> > версиями
> > и релизами. Я сделал так с php-manual и нисколько не жалею.
> 
> В этом случае получилось. Но можно придумать иакую ситуацию, где:
> 
> 1. нужно в главный пакет включить дополнительную документацию, которая не
> из исходников программы (например, README.ipl).
> 
> 2. Что-то из документационных файлов, входящих в состав распространяемых
> исходников, хочется исклюить из основного пакета и включить во
> вспомогательный doc.

Тогда придется собирать все в один присест и с одной архитектурой. Как
объяснил JBJ, архитектура влияет на процесс сборки, который в
вышеописанных случаях нельзя проводить отдельно для подпакетов. Если
крайне нужен отдельный noarch-подпакет (а на самом деле это лишь дань
эстетике, за исключением разве что случая дистрибутива, содержащего,
скажем, i586 и i686 "в одном флаконе" для всех пакетов - там действительно
хорошо выделить весь noarch и не дублировать его), можно продублировать
исходники или их часть в отдельном .src.rpm. Как хороший пример такого
рода могу привести apache и mod_ssl. Из исходников mod_ssl выделены
патчи и файлы, которые нужно приложить к Apache, и добавлены к пакету
apache. mod_ssl собирается при установленных apache и apache-devel, с
учетом того, что патчи приложены.

Насчет того, куда класть дополнительные файлы. Прямо в корень дерева, где
производится сборка, если они там не мешают. Вариант - создать подкаталог.
Для %doc указать их местонахождение относительно корня сборки. Чего же тут
сложного?

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

Почему в отдельном? Лежит она там вместе с остальными исходниками.

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

Множественные стадии %build - это, конечно, заманчиво, но это серъезная
модификация, а мы должны равняться на флагмана в море RPM - на RedHat
(кроме того, что у нас просто нет ресурсов делать такие вещи). Макросы
определять - еще куда ни шло, но серъезно нарушать совместимость не стоит.

-- 
Stay tuned,
  MhZ                                    mailto:mookid на sigent.ru
-----------
When I'm good, I'm great; but when I'm bad, I'm better.
		-- Mae West
_______________________________________________
Devel mailing list
Devel на linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel