/The Jargon File/

Андрей Боровский, kylixportal@narod.ru

Создание дистрибутива - финальный этап в процессе разработки приложения. Казалось бы все задачи уже решены и дело за малым. Самое естественное желание - запаковать приложение в .tar.gz архив. Однако, такой способ распространения двоичных файлов неудобен и не соответствует стандартам Linux, а ведь дистрибутив приложения, эта та "одежка", по которой пользователь будет встречать вашу программу. Так что имеет смысл потратить на создание дистрибутива некоторое время, тем более что в Linux это займет не "вторые 90" и даже не 10 процентов времени, отведенного на разработку.

Пакеты приложений можно собирать как из исходных текстов (при этом в процессе сборки пакета выполняется компиляция и сборка приложения), так и из готовых двоичных файлов. В первом случае нам потребуются исходные тексты приложения. Желательно (хотя и необязательно), чтобы исходные тексты сопровождались make-файлом¹ и были упакованы в архив tar.gz.

В качестве конкретного примера рассмотрим сборку пакета популярного приложения ORBit. ORBit - это свободно распространяемый CORBA-брокер, написанный на языке C++ (файл с исходными текстами можно загрузить с ftp://ftp.gnome.org/pub/GNOME/stable/sources/ORBit/ORBit-0.5.8.tar.gz).

Инструкции по сборке пакетов содержатся в специальных файлах (spec-файлы). Рассмотрим файл ORBit.spec, управляющий сборкой нашего пакета².

#
# Example spec file for ORBit package
#
%define prefix /usr
Summary: High-performance CORBA Object Request Broker.
Name: ORBit
Version: 0.5.8
Release: 1
Copyright: GPL/LGPL
Group: System Environment/Libraries
Source: ftp://ftp.gnome.org/pub/GNOME/Г
stable/sources/ORBit/ORBit-0.5.8.tar.gz
URL: http://www.labs.redhat.com/orbit/
BuildRoot: /var/tmp/orbit-%{PACKAGE_VERSION}-root
Prefix: %{prefix}
Docdir: %{prefix}/doc
Vendor: Red Hat, Inc.
Packager: Vasya Pupkin vasek@pupkin-network.ru

%description
Lots of advertising text here.

%prep
mkdir -p $RPM_BUILD_ROOT%{prefix}
zcat $RPM_SOURCE_DIR/ORBit-0.5.8.tar.gz | tar -xvf -

%build
cd ORBit-0.5.8
CFLAGS="$MYCFLAGS" ./configure --prefix=%prefix
make prefix=$RPM_BUILD_ROOT%{prefix}

%install
cd ORBit-0.5.8
make prefix=$RPM_BUILD_ROOT%{prefix} install
/sbin/ldconfig -n $RPM_BUILD_ROOT%{prefix}/lib
strip $RPM_BUILD_ROOT%{prefix}/bin/* || :
gzip -9 $RPM_BUILD_ROOT%{prefix}/info/*

%clean
rm -rf $RPM_BUILD_ROOT
rm -rf $RPM_BUILD_DIR/ORBit-0.5.8

%post -p /sbin/ldconfig

%postun -p /sbin/ldconfig

%files

%defattr(-,root,root)

%doc ORBit-0.5.8/AUTHORS ORBit-0.5.8/COPYING ORBit-0.5.8/ChangeLog ORBit-0.5.8/NEWS ORBit-0.5.8/README ORBit-0.5.8/TODO
%doc -P ORBit-0.5.8/libIDL/COPYING ORBit-0.5.8/libIDL/ChangeLog ORBit-0.5.8/libIDL/AUTHORS
%doc -P ORBit-0.5.8/libIDL/README* ORBit-0.5.8/libIDL/NEWS ORBit-0.5.8/libIDL/BUGS ORBit-0.5.8/libIDL/tstidl.c

%{prefix}/lib/lib*.so.*
%{prefix}/bin/orbit-event-server
%{prefix}/bin/orbit-name-server
%{prefix}/bin/name-client
%{prefix}/bin/orbit-ird

URL - URL проекта.

Раздел %description содержит "длинное" описание пакета, которое может состоять из нескольких строк.

Большинство разделов spec-файла содержат последовательности команд Linux, и очень похожи на файлы сценариев оболочки (shell scripts). Рассмотрим раздел %prep, в котором выполняются различные подготовительные операции. В этом разделе мы создаем "корневой" каталог приложения /var/tmp/orbit-0.5.8-root/usr (используя значения тэгов Prefix и BuildRoot) и распаковываем .tar.gz архив с исходными текстами приложения. Создание фиктивного корневого каталога для приложения не обязательно, но очень удобно. Дело в том, что в процессе сборки пакета по стандартной схеме выполняется не только компиляция и сборка, но также и установка приложения. Если вы не хотите, чтобы приложение ORBit устанавливалось в вашей системе всякий раз, когда вам нужно будет собрать пакет, лучше всего выполнить "псевдо-установку" в другой каталог, и удалить файлы приложения, когда они уже не будут нужны (мы еще вернемся к этому вопросу при рассмотрении раздела %filelist). Кроме команд Linux в разделе %prep можно использовать специальный макрос %setup, который подробно описан в документации.

Далее следует раздел %build в котором выполняется компиляция и сборка приложения. Вам может показаться странным, что процесс создания дистрибутива так тесно связан со сборкой приложения, однако не следует забывать, что RPM создавался для Linux-разработчиков, а отличительной чертой цикла разработки для Linux является выпуск большого числа промежуточных версий (snapshots). Кроме того, сборка приложений во время сборки пакета чрезвычайно облегчает процесс внесения обновлений (patches). В разделе %build мы сперва переходим в подкаталог ORBit-0.5.8, созданный в каталоге BUILD в процессе распаковки архива. Поскольку исходники ORBit предназначены для компиляции на разных платформах, перед сборкой приложения необходимо выполнить скрипт configure, который, кроме прочего, создаст make-файлы, соответствующие нашей системе. Далее запускаем утилиту make. Отмечу еще раз: использование make необязательно. Раздел %build может содержать любые команды, необходимые для сборки приложения, в том числе и прямые вызовы компилятора gcc.

За разделом %build следует раздел %install, в котором выполняется установка приложения. Обратите внимание, что приложение устанавливается в псевдо-корневой каталог /tmp/var/ORBit-0.5.8-root/usr, при этом в самой системе ничего не меняется.

Далее идет раздел %clean, который выполняется в самом конце процесса сборки, после записи готовых rpm-файлов на диск. В этом разделе мы рекурсивно удаляем псевдо-корневой каталог и подкаталог каталога BUILD, в котором содержались распакованные исходники.

Следующие разделы %post и %postun представляют собой post-install и post-uninstall скрипты. В отличие от рассмотренных выше разделов spec-файла, эти команды выполняются не в момент сборки пакета, а во время его установки на машине пользователя. Команды, содержащиеся в этих разделах, будут выполняться соответственно после установки и после удаления пакета из системы. В нашем файле оба раздела содержат только вызов утилиты ldconfig, в общем же случае сюда можно включать любые операции, например создание ярлыков приложения, настройку файлов конфигурации под конкретную систему и т. п. Для того, чтобы деинсталляция приложения выполнялась чисто, необходимо придерживаться следующего правили "все, что делается в %post, должно быть отменено в %postun".

Кроме разделов %post и %postun в spec-файлы можно включать разделы %pre и %preun, выполняемые соответственно перед установкой и удалением пакета. Например, в раздел %pre можно включить подготовительные действия, необходимые при установке приложения поверх уже установленной версии. К разделам, выполняющимся на машине пользователя, относится также раздел %verify, позволяющий проверить правильность установки пакета.

Заключает spec-файл раздел %files, являющийся, пожалуй, самой важной его частью. Этот раздел содержит список файлов, которые следует поместить в пакет. Файлы, не входящие в этот список, не будут помещены в пакет, даже если они были созданы в процессе сборки. В этом разделе мы используем несколько команд, призванных облегчить составления списка файлов. Директива %doc³ предназначена для переноса в пакет стандартной документации, т. е. файлов README, TODO, COPYING и иже с ними.

Обратите внимание на использование подстановочных символов (wildcards) в списке файлов. Здесь еще раз сказывается преимущество установки приложения в каталог BuildRoot. Если бы файлы переносились из каталогов /usr/bin и /usr/lib (что в принципе вполне допустимо), ссылка /usr/lib/lib*.so* привела бы к включению в пакет гораздо большего числа файлов, чем нам хотелось бы :-). При установке пакета пользователем, файлы, перечисленные в списке %files, будут устанавливаться в тех же каталогах, в которых они указаны в этом списке. Если тэг BuildRoot не используется, ссылки на файлы в разделе %files считаются абсолютными, так что, например, файл, указанный в списке %files как /usr/bin/somebinary, будет взят в пакет из каталога /usr/bin/ и будет установлен в одноименный каталог на машине пользователя. При использовании BuildRoot ссылки в разделе %files должны указываться относительно BuildRoot. Тогда при установке пакета пользователем эти файлы окажутся не в "фиктивном" корневом каталоге, а в "настоящем". Например, если тэг BuildRoot содержит значение /var/tmp/orbit-0.5.8-root/, файл /var/tmp/orbit-0.5.8-root/usr/bin/somefile должен указываться в разделе %files как /usr/bin/somefile. При установке в системе пользователя этот файл будет помещен в каталог /usr/bin/.

#include <stdio.h>
#include <stdlib.h>
#include <rpm/rpmlib.h>
#include <rpm/rpmio.h>
#include <rpm/header.h>
int main( int argc, char * argv[] ) {
FD_t fd;
Header hdr;
int isSource, major, minor, i, type, count;
const char ** fileList;
void * data;
if (argc != 2) {
printf("usage: %s <packet.rpm>\n", argv[0]);
return 0;
}
if ((fd = Fopen(argv[1], "r")) == 0) {
printf("%s: no such file.\n", argv[1]);
return 1;
}
if (rpmReadPackageHeader(fd, &hdr, &isSource, &major, &minor) != 0) {
printf("%s: bad file format\n", argv[1]);
Fclose(fd);
return 1;
}
printf("This is the %s package.\n", isSource == 0 ? "binary" : "source");
rpmHeaderGetEntry(hdr, RPMTAG_DESCRIPTION, &type, &data, &count);
printf("Package description: %s\n", data);
free(data);
rpmHeaderGetEntry(hdr, RPMTAG_VENDOR, &type, &data, &count);
printf("Package vendor: %s\n", data);
free(data);
rpmHeaderGetEntry(hdr, RPMTAG_PACKAGER, &type, &data, &count);
printf("Packed by %s\n", data);
free(data);
printf("press <Enter> to see the file list\n");
getchar();
rpmBuildFileList(hdr, &fileList, &сount);
printf("The files in the package are:\n");
for (i = 0; i < сount; printf("\t%s\n", fileList[i++]));
free(fileList);
Fclose(fd);
}

Maximum RPM: Taking the Red Hat Package Manager to the Limit, Edward C. Bailey. Доступно на сайте www.rpm.org

Статья была опубликована в журнале "Программист", #5, 2002 г. Перепечатка статьи возможна только с разрешения редакции журнала.