Нейл Мэтью - Основы программирования в Linux

# Это строка комментария.

Для того чтобы помочь пользователям решить, нужно ли им устанавливать ваш пакет, предоставьте секции Summaryи %description(обратите внимание на несогласованность RPM-синтаксиса, применяющего знак процента перед обозначением секции описания). Например, свой пакет вы можете описать следующим образом:

Summary: Trivial application

%description

MyApp Trivial Application

A trivial application used to demonstrate development tools.

This version pretends it requires MySQL at or above 3.23.

Authors: Neil Matthew and Richard Stones

Секция %descriptionможет состоять (и обычно состоит) из нескольких строк.

Файл spec может содержать сопутствующую информацию и о том, какие возможности предоставляет ваш пакет, и о том, от чего он зависит. (Вы также можете определить, от чего зависит пакет исходных файлов, например, указать специальные заголовочные файлы, необходимые для компиляции.)

Параметр Providesопределяет возможности, предоставляемые вашей системой. Например:

Provides: goodness

В примере утверждается, что пакет предоставляет вымышленную функциональную возможность, именуемую goodness(ценные свойства). RPM-система также автоматически добавляет элемент Providesк имени пакета, в данном случае myapp. Параметры Provides полезны в случае множественных пакетов, предоставляющих одну и ту же функциональную возможность. Например, пакет Web-сервера Apache предоставляет средство webserver. Другие пакеты, например Thy, могут предоставлять то же средство. (Для облегчения работы с конфликтующими пакетами RPM-система позволяет задавать также информацию с помощью элементов Conflicts и Obsoletes.)

Наиболее важная сопутствующая информация определяется в параметрах Requires. Вы можете указать все пакеты, необходимые для функционирования вашего пакета. Например, Web-серверу требуется сетевой пакет и пакет безопасности. В нашем примере вы задаете необходимость СУРБД MySQL версии 3.23 или более свежей. Синтаксическая запись приведена далее:

Requires: mysql >= 3.23

Если вам нужна СУРБД MySQL любой версии, можно задать параметр следующим образом:

Requires: mysql

RPM-система не разрешит пользователям устанавливать пакеты, если не установлены пакеты, необходимые для их работы. (Правда, пользователи могут переопределить это поведение.)

RPM-система автоматически добавляет зависимые элементы, например /bin/sh для сценариев командной оболочки, интерпретатор Perl для сценариев на языке Perl и любые совместно используемые библиотеки (файлы с расширением so), которые вызывает ваше приложение. Каждая новая версия RPM-системы включает все новые средства для автоматической проверки зависимостей.

После задания требований необходимо определить исходные файлы, формирующие ваше приложение. Для большинства приложений можно просто скопировать следующую строку:

source: %{name}-%{version}.tar.gz

Синтаксическая запись %{name}ссылается на RPM-макрос, в данном случае имя пакета. Поскольку ранее вы задали имя myapp, команда rpmbuildзаменит %{name}на myappи аналогично заменит %{version}на 1.0, для того чтобы использовать для построения файл с именем myapp-1.0.tar.gz. Искать этот файл она будет в каталоге SOURCES, описанном ранее.

В примере задается параметр Buildroot, определяющий место установки пакета. Вы можете скопировать в ваши пакеты следующую строку:

Buildroot: %{_tmppath}/%{name}-%{version}-root

После того как параметр Buildrootзадан, устанавливайте ваши приложения в каталог из параметра Buildroot. Можно использовать удобную переменную $RPM_BUILD_ROOT, которая задается для всех сценариев командной оболочки в файле spec.

После задания всех этих характеристик пакета далее нужно определить, как собирать пакет. Для этого есть четыре основные секции: %prep, %build, %installи %clean.

Судя по имени, секция %prepпредназначена для подготовки сборки. В большинстве случаев вы можете выполнить приведенный далее макрос %setupс параметром -qдля перевода его в режим без вывода сообщений:

%prep

%setup -q

Секция %buildсобирает ваше приложение. В большинстве случаев можно применять простую команду make. Например:

%build

make

Это один из способов, которым RPM-система использует уже проделанную вами работу по созданию make-файла.

Секция %installустанавливает ваше приложение, интерактивное справочное руководство и любые файлы поддержки. Вы можете применить RPM-макрос %makeinstall, который вызывает задание installmake-файла. Тем не менее, в данном случае установим файлы вручную, чтобы продемонстрировать дополнительные RPM-макросы:

%install

mkdir -р $RPM_BUILD_ROOT%{_bindir}

mkdir -p $RPM_BUILD_ROOT%{_mandir}

install -m755 myapp $RPM_BUILD_ROOT%{_bindir}/myapp

install -m755 myapp.1 $RPM_BUILD_ROOT%{_mandir}/myapp.1

В этом примере при необходимости создаются каталоги для файлов, а затем устанавливаются исполняемый файл myapp и интерактивное справочное руководство myapp.1. Переменная окружения $RPM_BUILD_ROOTсодержит местоположение Buildroot, заданное ранее. Макросы %{_bindir}и %{_mandir}замещаются текущим каталогом двоичных файлов и каталогом страниц интерактивного справочного руководства соответственно.

Если вы пользуетесь сценарием configure для создания make-файла, все разнообразные каталоги в нем будут заданы должным образом. В большинстве случаев вам не придется задать все команды установки вручную, как. показано в предыдущем примере.

Задание %cleanудаляет файлы, созданные командой rpmbuild. Например:

%clean

rm -rf $RPM_BUILD_ROOT

После описания построения пакета следует задать все файлы, которые будут устанавливаться. RPM-система очень строга на этот счет. Она и должна быть строгой для того, чтобы иметь возможность отследить должным образом каждый файл в каждом пакете. В секции %filesперечисляются имена всех файлов, включаемых в пакет. В данном случае у нас только два файла предназначены для распространения в двоичном пакете: исполняемый файл myapp и страница интерактивного справочного руководства myapp.1. Например:

%files

%{_bindir}/myapp

%{_mandir}/myapp.1

RPM-система может выполнять сценарий до и после установки вашего пакета. Например, если ваш пакет — процесс-демон, для его запуска, возможно, нужна корректировка сценариев установки системы. Сделайте это с помощью сценария %post. Далее приведен простой пример, отправляющий сообщение по электронной почте:

%post

mail root -s "myapp installed — please register"

Поищите примеры в серверных RPM-файлах spec.

Далее приводится полный файл spec для вашего простого приложения.

#

# spec file for package myapp (Version 1.0)