Блог

В процессе сборки пакета 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 будет равен нулю, и он будет установлен в папку по умолчанию. В приведенном выше случае это /usr/bin . Таким образом, $ RPM_BUILD_ROOT предназначен не только для упаковки или процесса «поддельной установки», но и для определения пользователем местоположения установки, аналогично выбору местоположения папки в Windows.

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

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

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

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

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

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

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

Итог:

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

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

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

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

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

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