Что на самом деле является $ RPM_BUILD_ROOT? - PullRequest
Новая
       36

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

31 голосов
/ 10 ноября 2011

В процессе сборки пакета 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.

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

Ответы [ 2 ]

35 голосов
/ 11 ноября 2011

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

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

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

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

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

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

Итог:

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

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

13 голосов
/ 06 февраля 2015

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

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

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

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