[devel] RPM: including additional docs

[Ivan Zakharyaschev]

	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