rpmbuild spec-файлы и rpm - некоторая путаница - PullRequest
0 голосов
/ 08 июня 2018

Я пытаюсь использовать rpmbuild для выполнения следующих действий.

У меня есть готовый проект, около 100 файлов в одном каталоге, как файл tar.Я хочу создать RPM, который будет связывать эти файлы, и при установке на новый компьютер с помощью rpm -i распакует файлы, создаст каталог в / usr / bin и скопирует их туда.Наконец, он должен запустить файл сценария bash.

Запуск rpmbuild -bs создает SRPM, но когда я пытаюсь установить его с помощью rpm -i, ничего не происходит.

При запуске rpmbuild -bb выполняются все шаги - настройка, сборка, установка и т. Д., Большинство из которых мне не нужно.Однако он не создает RPM, и шаг установки - это то, что я ожидал выполнить на целевой машине, когда использую rpm -i, а не на машине, на которой я пытаюсь создать RPM.

Я думаю, что мне не хватает чего-то простого.Есть намеки?

1 Ответ

0 голосов
/ 08 июня 2018

Запуск rpmbuild -bs создает SRPM, но когда я пытаюсь установить его с помощью rpm -i, ничего не происходит.

Не ничего .Успешная установка SRPM устанавливает файл спецификации и исходные коды (включая исправления) в дерево сборки RPM , готовые для создания RPM.Однако, в зависимости от того, где вы его построили и от кого вы его установили, это могло бы просто перезаписать ваши исходные источники и спецификации идентичными копиями.SRPM - это не то, что вам нужно, хотя вы все равно должны создать его для своего будущего использования.

Запуск rpmbuild -bb позволяет выполнить все шаги - настроить, собрать, установить и т. Д., Большинствоиз которых мне не нужно.

Ну конечно, но шаги, которые вам не нужны, не должны делать ничего.Звучит так, будто вы можете обойтись без пустого сценария %build и с пустым сценарием %prep, если знаете, как.Большая часть работы может быть выполнена в %install, и это нормально.

Однако, это не создает RPM,

Это было бы удивительно.Вы уверены, что ищете в правильном месте?Он перейдет в соответствующий подкаталог arch 10 * в вашей области сборки RPM.Например, RPMS/x86_64/mypackage-1.2.3-1.x86_64.rpm.

Но только если, конечно, rpmbuild удастся.Он может завершиться ошибкой после этапа %install по разным причинам, но при этом выдает диагностическое сообщение.

, и этап установки - это то, что я ожидал на целевой машине при использовании rpm -я не на той машине, на которой я пытаюсь создать RPM.

Ну, отчасти это зависит от того, как вы пишете скрипт установки в своей спецификации.Если вы напишите правильно, файлы будут упакованы в промежуточную область, обозначенную вами как rpmbuild.

Я думаю, что мне не хватает чего-то базового.Есть намеки?

Я думаю, что вам не хватает нескольких базовых вещей:

  1. Правило № 1 оборотов здания: не создавайте RPM как root! То, что вы говорите, что шаг установки делает то, что вы ожидаете от rpm -i, говорит мне, что вы нарушаете это правило.Только если вы создаете с правами root, rpmbuild сможет записывать файлы в системные каталоги.

  2. Скриплет %install (предоставленный вами в файле спецификации) должен писатьфайлы в образе файловой системы с корнем в корне сборки, предоставленном rpmbuild, а не в основное дерево, корнем которого является настоящий корень файловой системы.Скриплет %install может идентифицировать корень сборки с помощью макроса %{buildroot} или переменной оболочки $BUILDROOT.Скриплет должен создать этот каталог и любые подкаталоги, в которых он нуждается, и записать файлы для установки туда .

  3. Можно предоставить скрипты для запуска при установке пакетаи / или время удаления, и это довольно часто, но убедитесь, что вы делаете то, что может быть сделано только в целевой системе, после установки файлов пакета.Создание локальных пользователей и настройка системных служб являются примерами.Не используйте такие скриптлеты, чтобы делать что-либо, что вы могли бы запекать прямо в пакете, например устанавливать владельца файла или права доступа или изменять файлы.

В целом, звучит так, как будто вы хотите что-тоэти строки:

Name:           mypackage
Version:        1.2.3
Release:        1%{?dist}
Summary:        My package

License:        proprietary
Source0:        mypackage-1.2.3.tar.gz

# Only rather old rpmbuild requires you to choose a build root yourself
# BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

# You probably can let rpmbuild discover the dependencies for you
# Requires:       

%description
My cool package.

%prep
# empty 

%build
# empty

%install
# make sure to start clean
rm -rf %{buildroot}

# Create the buildroot and appropriate directory structure within
mkdir -p %{buildroot}%{_bindir}
cd %{buildroot}%{_bindir}

# Unpack the tarball directly into the build root.
# This is a bit unusual, but it works when your tarball contains pre-built
# binaries.  The macro %{S:0} refers to source 0.
tar -xzf %{S:0}

# Optionally move / rename the unpacked directory or its contents    
mv mypackage-1.2.3 mypackage

%files
# Installed files will be owned by root:root, but they will have whatever
# modes they do in the build root:
%defattr(-,root,root,-)

# Or whatever the install directory was, less the build root portion:
%{_bindir}/mypackage

%post
# post-installation script inline here ...
# Can use the installed files, including running scripts among them.
# Make sure that this script cannot exit with a nonzero exit status.

%changelog
* Fri Jun 08 2018 user3587642 <user3587642@mail.com> 1.2.3-1
- Initial spec
...