Текст книги "Основы программирования в Linux"

Автор книги: Нейл Мэтью

Соавторы: Ричард Стоунс
сообщить о нарушении

Текущая страница: 37 (всего у книги 67 страниц)

Установка RPM-пакетов

Для установки RPM-пакета запустите команду rpm. Формат очень простой:

rpm -Uhv name-version-release.architecture.rpm

Например,

$ rpm -Uhv MySQL-server-5.0.41-0.glibc23.i386.rpm

Эта команда устанавливает (или при необходимости обновляет) пакет сервера СУРБД MySQL для системы на базе Intel x86.

Команда rpm обеспечивает большую часть взаимодействия пользователя с RPM-системой. Вы можете узнать, установлен ли пакет, с помощью следующей команды:

$ rpm -qa xinetd

xinetd-2.3.14-40

Формирование RPM-пакетов

Для создания RPM-пакета выполните команду rpmbuild. Процесс относительно прост. Вы должны сделать следующее:

1. Собрать программное обеспечение, которое хотите поместить в пакет.

2. Создать файл spec, описывающий, как собирать пакет.

3. Сформировать пакете помощью команды rpmbuild.

Поскольку создание RPM-пакета может быть очень сложным, мы будем придерживаться в этой главе простого примера, достаточного для распространения приемлемого приложения в виде исходного или двоичного файла. Более таинственные опции и поддержку пакетов, полученных с помощью файлов исправлений (patches), мы оставим любознательным читателям. Для получения дополнительной информации изучите страницу интерактивного справочного руководства, посвященную программе rpm, или справочное руководство RPM HOWTO (обычно хранящееся в каталоге /usr/share/doc). Кроме того, прочтите книгу Эрика Фостера-Джонсона (Eric Foster-Johnson) "Red Hat RPM Guide" ("Справочник по Red Hat RPM"), доступную в интерактивном режиме на Web-сайте http://docs.fedoraproject.org/drafts/rpm-guide-en/.

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

Сбор программного обеспечения

Первый этап в создании RPM-пакета – сбор программного обеспечения, которое вы хотите поместить в пакет. Чаще всего у вас есть исходный программный код приложения, файл сборки, например make-файл, и, возможно, страница интерактивного справочного руководства.

Самый легкий способ собрать это программное обеспечение – упаковать файлы в сжатый tar-файл. Назовите файл архива именем приложения и укажите в нем номер версии, например, myapp-1.0.tar.gz.

Вы можете откорректировать ранее созданный make-файл Makefile6, добавив новое задание на упаковку файлов в сжатый файл архива. Окончательная версия make-файла, названная просто Makefile, выглядит следующим образом:

all: myapp

# Какой компилятор

CC = gcc

# Где хранятся файлы include

INCLUDE = .

# Опции для разработки

CFLAGS = -g -Wall -ansi

# Опции для рабочей версии

# CFLAGS = -О -Wall -ansi

# Локальные библиотеки

MYLIB = mylib.a

myapp: main.о $(MYLIB)

 $(CC) -о myapp main.о $(MYLIB)

$(MYLIB) : $(MYLIB)(2.o) $(MYLIB)(3.о)

main.о: main.c a.h

2.o: 2.с a.h b.h

3.o: 3.c b.h c.h

clean:

 -rm main.о 2.о 3.o $(MYLIB)

dist: myapp-1.0.tar.gz

myapp-1.0.tar.gz: myapp myapp.1

 -rm -rf myapp-1.0

 mkdir myapp-1.0

 cp *.c *.h *.1 Makefile myapp-1.0

 tar zcvf $@ myapp-1.0

Задание myapp-1.0.tar.gz в make-файле формирует сжатый архив (tarball) из исходных файлов нашего простого примера приложения. Этот код вставлен для простоты в задание dist, в котором вызываются те же команды. Для создания файла архива выполните следующую команду:

$ make dist

Далее нужно скопировать файл myapp-1.0.tar.gz в каталог RPM-пакетов SOURCES, обычно в системе Red Hat Linux это каталог /usr/src/redhat/SOURCES, а в системе SUSE Linux – /usr/src/packages/SOURCES. Например:

$ cp myapp-1.0.tar.gz /usr/src/redhat/SOURCES

RPM-система полагает, что исходные файлы находятся в каталоге SOURCES в виде tar-файлов. (Есть и другие опции, но эта самая простая.) SOURCES – это один из каталогов, на которые рассчитывает RPM-система.

RPM-система полагается на пять каталогов, приведенных в табл. 9.4.

Таблица 9.4

BUILD	Команда rpmbuild создает программное обеспечение в этом каталоге
RPMS	Команда rpmbuild хранит в этом каталоге созданные ею двоичные файлы
SOURCES	В этот каталог следует поместить исходные файлы для вашего приложения
SPECS	В этот каталог следует помещать файлы spec для всех RPM-пакетов, которые вы планируете создать, хотя это и не обязательно
SRPMS	Команда rpmbuild помещает в этот каталог RPM-пакеты из исходных файлов

У каталога RPMS обычно есть ряд подкаталогов, определяющих тип архитектуры системы, например такие, как приведенные далее (для системы с архитектурой Intel х86).

$ ls RPMS

athlon

i386

i486

i586

i686

noarch

В системах Red Hat Linux по умолчанию предполагается, что RPM-пакеты создаются в каталоге /usr/src/redhat.

Примечание

Этот каталог специфичен для системы Red Hat Linux. В других дистрибутивах Linux используются иные каталоги, например каталог /usr/src/packages.

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

Создание RPM-файла spec

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

Примечание

Хорошими источниками примеров файлов spec служат другие RPM-пакеты. Посмотрите RPM-пакеты исходных файлов, хранящиеся в файлах с окончанием .src.rpm. Установите эти RPM-пакеты и просмотрите их файлы spec. Вы найдете гораздо более сложные примеры, чем те, которые вам когда-либо понадобятся. Интересные примеры можно найти среди файлов spec, предназначенных для пакетов anonftp, telnet, vnc и sendmail.

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

В данном примере вы создаете файл spec для простого приложения myapp. Назовите его myapp.spec. Начинает файл spec с набора определения имени, номера версии и другой информации о вашем пакете. Например,

Vendor:       Wrox Press

Distribution: Any

Name:         myapp

Version:      1.0

Release:      1

Packager:     [email protected]

License:      Copyright 2007 Wiley Publishing, Inc

Group:        Applications/Media

Эту секция RPM-файла spec часто называют заголовком. В ней содержатся наиболее важные параметры Name, Version и Release. В нашем примере имя – myapp, номер версии – 1.0 и номер выпуска или сборки RPM-пакета – 1, т.к. эта ваша первая попытка создания RPM-пакета.

Параметр Group применяется для облегчения графической инсталляции программ, сортируя тысячи приложений для системы Linux по типам. Элемент Distribution важен, если вы создаете пакет для одного дистрибутива Linux, например, Red Hat или SUSE Linux.

Неплохо добавить в ваш файл spec комментарии. Как и сценарии командной оболочки, и make-файлы, команда rpmbuild считает комментарием любую строку, начинающуюся с символа #. Например:

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

Для того чтобы помочь пользователям решить, нужно ли им устанавливать ваш пакет, предоставьте секции 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, который вызывает задание install make-файла. Тем не менее, в данном случае установим файлы вручную, чтобы продемонстрировать дополнительные 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)

#

Vendor:       Wrox Press

Distribution: Any

Name:         myapp

Version:      1.0

Release:      1

Packager:     [email protected]

License:      Copyright 2007 Wiley Publishing, Inc.

Group:        Applications/Media

Provides:     goodness

Requires:     mysql >=3.23

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

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

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

%prep

%setup -q

%build

make

%install

mkdir -p $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

%clean

rm -rf $RPM_BUILD_ROOT

%post

mail root -s «myapp installed – please register»

%files

%{_bindir}/myapp

%{_mandir}/myapp.1

Теперь вы готовы к формированию RPM-пакета.

Создание RPM-пакета с помощью rpmbuild

Создаются пакеты с помощью команды rpmbuild со следующей синтаксической записью:

rpmbuild -bBuildStage spec_file

Опция -b заставляет rpmbuild создать RPM-пакет. Дополнительная опция BuildStage – специальный код, информирующий команду rpmbuild о том, как далеко она может зайти в процессе создания. В табл. 9.5 перечислены опции команды.

Таблица 9.5

-ba	Создавать и двоичный, и исходный RPM-пакет
-bb	Создавать двоичный RPM-пакет
-bc	Компилировать программу, но не создавать полный RPM-пакет
-bp	Подготовиться к созданию двоичного RPM-пакета
-bi	Создать двоичный RPM-пакет и установить его
-bl	Проверить список файлов RPM-пакета
-bs	Создать только RPM-пакет исходных файлов

Для создания двоичного RPM-пакета и пакета исходных файлов используйте опцию -ba. RPM-пакет исходных файлов позволит создать повторно двоичный RPM– пакет.

Скопируйте RPM-файл spec в корректный каталог SOURCES, поместив его рядом с исходным файлом приложения:

$ cp myapp.spec /usr/src/redhat/SOURCES

Далее приведен вывод, сопровождающий создание пакета в системе SUSE Linux, пакеты в которой создаются из каталога /usr/src/packages/SOURCES:

$ rpmbuild -ba myapp.spec

Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.47290

+ umask 022

+ cd /usr/src/packages/BUILD

+ cd /usr/src/packages/BUILD

+ rm -rf myapp-1.0

+ /usr/bin/gzip -dc /usr/src/packages/SOURCES/myapp-1.0.tar.gz

+ tar -xf -

+ STATUS=0

+ '[' 0 -ne 0 '] '

+ cd myapp-1.0

++ /usr/bin/id -u

+ '[' 1000 = 0 ']'

++ /usr/bin/id -u

+ '[' 1000 = 0 ']'

+ /bin/chmod -Rf a+rX, u+w, g-w, o-w

+ exit 0

Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.99663

+ umask 022

+ cd /usr/src/packages/BUILD

+ /bin/rm -rf /var/tmp/myapp-1.0-root

++ dirname /var/tmp/myapp-1.0-root

+ /bin/mkdir -p /var/tmp

+ /bin/mkdir /var/tmp/myapp-1.0-root

+ cd myapp-1.0 + make

gcc -g -Wall -ansi -с -o main.о main.c

gcc -g -Wall -ansi -с -o 2.o 2.c

ar rv mylib.a 2.o

ar: creating mylib.a

a – 2.о

gcc -g -Wall -ansi -с -o 3.o 3.c

ar rv mylib.a 3.o

a – 3.o

gcc -o myapp main.о mylib.a

+ exit 0

Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.47320

+ umask 022

+ cd /usr/src/packages/BUILD

+ cd myapp-1.0

+ mkdir -p /var/tmp/myapp-1.0-root/usr/bin

+ mkdir -p /var/tmp/myapp-1.0-root/usr/share/man

+ install -m755 myapp /var/tmp/myapp-1.0-root/usr/bin/myapp

+ install -m755 myapp.1 /var/tmp/myapp-1.0-root/usr/share/man/myapp.1

+ RPM_BUILD_ROOT=/var/tmp/myapp-1.0-root

+ export RPM_BUILD_ROOT

+ test -x /usr/sbin/Check -a 1000 = 0 -o

 -x /usr/sbin/Check -a '!' -z /var/tmp/myapp-1.0-root

+ echo 'I call /usr/sbin/Check...'

I call /usr/sbin/Check...

+ /usr/sbin/Check

-rwxr-xr-x 1 neil users 926 2007-07-09 13:35 /var/tmp/myapp-1.0-root/ /usr/share/man/myapp.1.gz

Checking permissions and ownerships – using the permissions files

 /tmp/Check.perms.017506

setting /var/tmp/myapp-1.0-root/ to root:root 0755 (wrong owner/group neil:users)

setting /var/tmp/myapp-1.0-root/usr to root:root 0755. (wrong owner/group neil:users)

+ /usr/lib/rpm/brp-compress

+ /usr/lib/rpm/brp-symlink

Processing files: myapp-1.0-1

Finding Provides: /usr/lib/rpm/find-provides myapp

Finding Requires: /usr/lib/rpm/find-requires myapp

Finding Supplements: /usr/lib/rpm/find-supplements myapp

Provides: goodness

Requires(interp): /bin/sh

Requires(rpmlib): rpmlib(PayloadFilesHavePrefix) <= 4.0-1

 rpmlib (CompressedFileNames) <= 3.0.4-1

Requires(post): /bin/sh

Requires: mysql >= 3.23 libc.so.6 libc.so.6 (GLIBC 2.0)

Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/myapp-1.0-root

Wrote: /usr/src/packages/SRPMS/myapp-1.0-1.src.rpm

Wrote: /usr/src/packages/RPMS/i586/myapp-1.0-1.i586.rpm

Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.10065

+ umask 022

+ cd /usr/src/packages/BUILD

+ cd myapp-1.0

+ rm -rf /var/tmp/myapp-1.0-root

+ exit 0

Когда сборка будет закончена, вы должны увидеть два пакета: двоичный RPM-пакет в подкаталоге с названием типа архитектуры, например i586 каталога RPMS, и RPM-пакет исходных файлов в каталоге SRPMS.

У файла двоичного RPM-пакета будет имя, похожее на следующее:

myapp-1.0-1.i586.rpm

У вашей системы может быть другая архитектура.

Имя файла RPM-пакета исходных файлов будет следующим:

myapp-1.0-1.src.rpm

Примечание

Пакеты должен устанавливать суперпользователь. Создавать пакеты от имени пользователя root нет необходимости, если у вас есть права на запись в каталоги RPM-системы, обычно это каталоги /usr/src/redhat. Как правило, не следует создавать RPM-пакеты как пользователь root, потому что в файле spec могут быть команды, способные повредить вашу систему.

Пакеты других форматов

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

Дистрибутивы Linux Debian и на основе Debian (а также некоторые другие) поддерживают другой формат упаковки, по функциональности похожий на RPM и именуемый dpkg. Утилита dpkg дистрибутива Debian распаковывает и устанавливает файлы пакета, обычно имеющие расширение deb. Если вам нужно распространять приложение как файл пакета с расширением deb, можно преобразовать RPM-пакет в формат dpkg с помощью утилиты Alien. Дополнительную информацию о ней можно найти на Web-сайте http://kitenet.net/programs/alien/.

Среды разработки

Почти все средства, рассматриваемые до сих пор в этой главе, по существу представляют собой средства режима командной строки. У разработчиков, работавших в ОС Windows, несомненно есть опыт работы с интегрированными средами разработки (IDE, Integrated Development Environment). IDE – это графическая оболочка, в которой собраны вместе все или некоторые средства, необходимые для создания, отладки и выполнения приложения. Обычно она как минимум содержит редактор, обозреватель файлов и средство для выполнения приложения и перехвата результата. В более полные среды включена поддержка генерации исходных файлов на базе шаблонов, разработанных для приложений определенных типов, интеграция с системой управления исходным программным кодом и автоматическое документирование.

В следующих разделах мы рассмотрим одну такую IDE, KDevelop, и упомянем другие IDE, доступные для ОС Linux сегодня. Эти среды разработки активно развиваются, и лучшие из них начинают конкурировать с коммерческими предложениями.

Назад к карточке книги "Основы программирования в Linux"