Что на самом деле $RPM_BUILD_ROOT?

В процессе создания пакета RPM я должен указать BuildRoot, а позже будет использоваться в% install, который вызывает $RPM_BUILD_ROOT. Я всегда думаю, что $RPM_BUILD_ROOT - это поддельная установка для RPM для упаковки. Затем, во время установки с использованием пакета RPM, он будет установлен в фактическое местоположение. Например:

$RPM_BUILD_ROOT/usr/bin

Я думал, что $RPM_BUILD_ROOT предназначен только для процесса упаковки, и в некотором роде RPM может отличить $RPM_BUILD_ROOT и фактическое место установки, когда пользователь выполняет "rpm -ivh package.rpm", будет /usr/bin.

Но недавно, прочитав некоторые документы, предлагается, что $RPM_BUILD_ROOT - это фактическое место, которое будет установлено, и $RPM_BUILD_ROOT задается пользователем с настройкой переменной среды $RPM_BUILD_ROOT, чтобы позволить пользователям установить пакет в местах их желаний. В противном случае $RPM_BUILD_ROOT будет null, и он будет установлен в местоположение по умолчанию. В приведенном выше случае это /usr/bin. Таким образом, $RPM_BUILD_ROOT предназначен не только для процесса упаковки или "поддельной установки", но и для пользователя, чтобы определить местоположение установки, аналогично выбору местоположения папки в Windows.

Я не знаю, что мое мышление верное или нет. Может кто-нибудь, пожалуйста, подтвердите? Спасибо заранее.

Ответы

Ответ 1

$RPM_BUILD_ROOT (или эквивалентный макрос файла SPEC %{buildroot}) всегда содержит каталог, в котором RPM будет искать любые файлы для упаковки. Скрипты RPM (например, script, который сжимает страницы руководства) также будут использовать это значение, чтобы знать, где искать только что установленные файлы. Обычно это значение будет непустым и содержать местоположение вдали от системных каталогов - обычно где-то под /tmp или /var/tmp.

Предполагается, что автор файла SPEC должен удостовериться, что make install (или любой другой установщик, о котором идет речь в этом случае) помещает любые файлы под $RPM_BUILD_ROOT с той же иерархией, которая должна использоваться, когда программное обеспечение наконец, установлен. Например. чтобы установить RPM ls в /bin/ls, раздел файла %install SPEC должен убедиться, что ls помещен в $RPM_BUILD_ROOT/bin/ls.

Предполагается, что автор файла SPEC также будет использовать тег BuildRoot:, чтобы указать правильное местоположение. В качестве альтернативы, система сборки может иметь конфигурационный файл rpmrc RPM с соответствующей записью. В в любом случае должен быть установлен корень сборки, чтобы:

  • Обычные пользователи смогут создавать исходный пакет.

  • Если суперпользователь когда-либо создаст исходный пакет, процесс сборки не будет клонировать любые системные файлы, если суперпользователь не установит полученный двоичный пакет. И да, может быть веская причина для сборки некоторых пакетов как root - например, для запуска полного glibc testuite для <тестов > требуются root привилегии.

Тем не менее, RPM может и будет строить пакет с пустой корневой переменной. В этом случае как установка сборки, так и конечные места назначения совпадут. Потенциальный вызов, например, make install будет использовать местоположения по умолчанию, таким образом, сбивая системные файлы, например, /usr/lib, если выполняется с достаточными привилегиями. Кроме того, наличие /usr/bin/* в вашем разделе %files с удовольствием вытащит все содержимое каталога сборки /usr/bin/ в ваш двоичный пакет.

Нижняя строка:

  • Никогда не используйте пустой root.

  • Не создавайте пакеты как root, если нет другого пути.

Ответ 2

файл ~/.rpmmacros определяет пути для каждого пользователя:

%_topdir %(echo $HOME)/rpmbuild
%_tmppath %{_topdir}/tmp

и их также можно определить с помощью параметров командной строки rpmbuild:

rpmbuild --define '_topdir /home/username/rpmbuild'