Запуск 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 оборотов здания: не создавайте RPM как root! То, что вы говорите, что шаг установки делает то, что вы ожидаете от rpm -i
, говорит мне, что вы нарушаете это правило.Только если вы создаете с правами root, rpmbuild
сможет записывать файлы в системные каталоги.
Скриплет %install
(предоставленный вами в файле спецификации) должен писатьфайлы в образе файловой системы с корнем в корне сборки, предоставленном rpmbuild, а не в основное дерево, корнем которого является настоящий корень файловой системы.Скриплет %install
может идентифицировать корень сборки с помощью макроса %{buildroot}
или переменной оболочки $BUILDROOT
.Скриплет должен создать этот каталог и любые подкаталоги, в которых он нуждается, и записать файлы для установки туда .
Можно предоставить скрипты для запуска при установке пакетаи / или время удаления, и это довольно часто, но убедитесь, что вы делаете то, что может быть сделано только в целевой системе, после установки файлов пакета.Создание локальных пользователей и настройка системных служб являются примерами.Не используйте такие скриптлеты, чтобы делать что-либо, что вы могли бы запекать прямо в пакете, например устанавливать владельца файла или права доступа или изменять файлы.
В целом, звучит так, как будто вы хотите что-тоэти строки:
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