On Tue, Feb 19, 2008 at 03:10:40AM +0300, Dmitry V. Levin wrote:
> > Работает это так: скрипт сохраняется в %buildroot/.pre:%name.
> > Дальше на него натравливается весь набор имеющихся *.req
> > скриптов (почти так же, как в обычном find-requires).
> > 
> > Проблемы тут есть такие:
> > 1) Акт волюнтаризма: %buildroot/.* становится зарезервированными
> > путями для сохранения информации о пакете; туда же теперь сохраняется,
> > например, список файлов в пакете: %buildroot/.files:%name.
> > 2) Если каталога %buildroot не существует, то скрипт не удастся
> > сохранить, и с некоторой руганью сборка пойдёт дальше.  Каталога
> > %buildroot не существует, если, например, в spec'е нету секции
> > %install.
> > 
> > По нескольким разным причинам (не слишком веским),
> > поиск зависимостей в скритплетах желательно вести так,
> > как если бы этот скриптлет физически лежал в %buildroot'е.
> > Ещё точнее, желательно чтобы скриптлет лежал
> > в %buildroot/sbin/.pre:%name ...
> 
> Что за причины помещать временные файлы в %buildroot?

Вот две причины:

1) На стадии find-requires rpm не переходит в сборочный каталог
пакета, а только в ~/RPM/BUILD.  Это значит, что на стадии find-requires
нельзя "подсмотреть" в сборочный каталог пакета, а, выходит, если нужно
передать какой-то хинт в поиск зависимостей, то это можно сделать только
через %buildroot.  По этой причине иногда создаётся файл %buildroot/.perl.req.

2) Иногда желательно знать список файлов, запакованных в пакет.
Опять же, выходит дёшево и сердито писать этот список файлов
в $RPM_BUILD_ROOT/.files:$RPM_SUBPACKAGE_NAME, и тогда все
заинтересованные скрипты смогут прямо или косвенно туда подсмотреть.

В общем, программирование на шелле (и, в частности, то что делается
в rpm-build) навязывает сильное разделение данных и жесткий data flow.
Мы считаем, что мы можем искать "искать зависимости данного типа
в данном файле".  Реально же контесты бывают сложнее: в shell.req
приходится фактически обрабатывать не по одному файлу, а все сразу,
чтобы удалить зависимости на функции, которые определены в других
файлах.  В find-package для ослабления зависимостей на каталоги
приходится проверять, не запакованы ли какие-то файлы в этих каталогах
(тогда каталог гарантированно существует).  В случае с shell.req удаётся
обойтись без "обмена данных" за пределами скрипта, а в find-package
нужно уже знать внешний по отношению к задаче контекст.

Тут меня застигают философские размышления, что модульность --
это на самом деле фикция.  Мир -- это единое целое, и в нём всё
неразрывно связано со всем, а выделение объектов есть произвольный
акт нашего мышления.  Значит, модульность нужна постольку, поскольку
_нам_ удобнее притворяться и видеть некоторые вещи более модульными,
чем они есть на самом деле.  Ничего плохого в этом нет.  В случае
с rpm конструкция оказывается слишком жесткой, когда возникает
потребность подсмотреть в более глобальный контекст по отношению
к текущему контексту.  Где сохранять эти более глобальные
контексты не особо понятно, глобальных переменных у нас нету.
Приходит в голову плюхнуть их в %buildroot.