ALT Linux Team development discussions
 help / color / mirror / Atom feed
* [devel] RPM: including additional docs
@ 2000-11-23 18:46 Ivan Zakharyaschev
  2000-11-23 22:09 ` Mikhail Zabaluev
  0 siblings, 1 reply; 5+ messages in thread
From: Ivan Zakharyaschev @ 2000-11-23 18:46 UTC (permalink / raw)
  To: devel

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

Пользуясь 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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [devel] RPM: including additional docs
  2000-11-23 18:46 [devel] RPM: including additional docs Ivan Zakharyaschev
@ 2000-11-23 22:09 ` Mikhail Zabaluev
  2000-11-25 10:04   ` Ivan Zakharyaschev
  0 siblings, 1 reply; 5+ messages in thread
From: Mikhail Zabaluev @ 2000-11-23 22:09 UTC (permalink / raw)
  To: devel

Hello Ivan,

On Thu, Nov 23, 2000 at 21:46 +0300, Ivan Zakharyaschev wrote:
>
> 	Добрый вечер!
> 
> Пользуясь RPM для сборки пакетов, столкнулся с некоторыми проблемами.
> После обдумывания и попыток найти решения, мне пришло в голову несколько
> мыслей по поводу возможных усовершенствований RPM. Думаю, что нет смысла
> их не высказать.
> 
> Проблема: в пакет включается дополнительная документация, которая берется
> из отдельных файлов (они указаны как SourceX). Эти файлы могут
> представлять из себя как архивы, так и просто файлы, включаемые в пакет
> почти без изменений. Проблема в том, на какой стадии сборки пакета их
> разархивировать (если это архив) и как (какой директивой) включать в пакет
> на заключительном этапе (%files, %doc).

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

-- 
Stay tuned,
  MhZ                                    mailto:mookid@sigent.ru
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [devel] RPM: including additional docs
  2000-11-23 22:09 ` Mikhail Zabaluev
@ 2000-11-25 10:04   ` Ivan Zakharyaschev
  2000-11-25 11:41     ` Mikhail Zabaluev
  0 siblings, 1 reply; 5+ messages in thread
From: Ivan Zakharyaschev @ 2000-11-25 10:04 UTC (permalink / raw)
  To: devel

	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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [devel] RPM: including additional docs
  2000-11-25 10:04   ` Ivan Zakharyaschev
@ 2000-11-25 11:41     ` Mikhail Zabaluev
  2000-11-25 21:03       ` Ivan Zakharyaschev
  0 siblings, 1 reply; 5+ messages in thread
From: Mikhail Zabaluev @ 2000-11-25 11:41 UTC (permalink / raw)
  To: devel

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [devel] RPM: including additional docs
  2000-11-25 11:41     ` Mikhail Zabaluev
@ 2000-11-25 21:03       ` Ivan Zakharyaschev
  0 siblings, 0 replies; 5+ messages in thread
From: Ivan Zakharyaschev @ 2000-11-25 21:03 UTC (permalink / raw)
  To: devel

	Hello!

On Sat, 25 Nov 2000, Mikhail Zabaluev wrote:

> Тогда придется собирать все в один присест и с одной архитектурой. Как
> объяснил JBJ, архитектура влияет на процесс сборки, который в

В общем случае влияет на процесс сборки. Мы же хотим научиться описывать
разумные исключения.

> вышеописанных случаях нельзя проводить отдельно для подпакетов. Если
> крайне нужен отдельный noarch-подпакет (а на самом деле это лишь дань

Если крайне нужен, то можно еще обмануть RPM (исползуя --short-cicuit с
-bi и -bb с разными targets): но тогда будут проблемы с системами
автоматической сборкм и с тем, чтобы объяснить другим, как получилось
собрать такие пакеты.

> эстетике, за исключением разве что случая дистрибутива, содержащего,
> скажем, i586 и i686 "в одном флаконе" для всех пакетов - там
> действительно
> хорошо выделить весь noarch и не дублировать его), можно продублировать

Можно использовать довольно грубый метод для избежания дублирования:
сравнивать содержательную часть пакетов, построенных для разных targets, и
если они не отличаются, то исключать один. (В основном все собирается для
i586 и i686, поэтому вместо дублирующего пакета для i686 можно ставить
ссылку на тот, который для i586: при таком способе выявления дубликатов
нет гарантии того, что обнаружен настоящий noarch.)

> Для %doc указать их местонахождение относительно корня сборки. Чего же
> тут
> сложного?

Да ничего. Никаких серьезных практических проблем я не вижу. Как Вы
сами сказали, все это эстетика.

> > именно тут удобно? То, что документация готовится к установке в
> отдельном
> > файловом пространстве ($RPM_BUILD_DIR).
>
> Почему в отдельном? Лежит она там вместе с остальными исходниками.

Может, "файловое пространтсво" мною неправильно употреблено. Я имел в виду
самое обыкновенное свойство RPM: что сборка не поднимается выше
BUILD/name-ver/ и никто другой туда не залезает, что обеспечивает
независимость сборок разных пакетов.

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

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

%build
...

%builddoc
...

Модифицированный RPM поймет это как две параллельные стадии build.

А если нынешнему RPM определить %buildoc как пустой макрос, то он выполнит
последовательно описанные действия, в результате чего будет собрана
программа и документация. Если написавший это не полагался на то, что
деревья сборки одного и другого разные (если нет одинаковых имен), то
проблем не будет. Такую сборку ("старым" rpm собирать по spec-файлу для
модифицированного) кто-то может захотеть провести только для получения
пакета для личного пользования, и поэтому те проблемы удобства, которые
стояли перед упаковщиком и которые решали модификации RPM, его волновать
не будут:

-- какие-то пакеты вместо noarch получатся его архитектуры, он их себе и
установит (я говорю, суммируя все предложенные новые возможности);

-- документация распакуется на стадии %prep -- ну и что, он ведь не будет
вносить в нее изменения и много раз пересобирать пакет.

А packager'ы могут пользоваться модифицированной версией для создания
более приятного дистрибутива и удобства работы.

-- 
Best regards,
      Ivan Z.

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2000-11-25 21:03 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-11-23 18:46 [devel] RPM: including additional docs Ivan Zakharyaschev
2000-11-23 22:09 ` Mikhail Zabaluev
2000-11-25 10:04   ` Ivan Zakharyaschev
2000-11-25 11:41     ` Mikhail Zabaluev
2000-11-25 21:03       ` Ivan Zakharyaschev

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git