Построить пакеты RPM довольно легко, особенно если вы можете получить программное обеспечение, которые вы пытаетесь упаковать чтобы построить для себя.
Основные процедуры чтобы построить пакет RPM следующие:
/etc/rpmrc установлен на вашей
системе.
При нормальных условиях, RPM построит и двоичный пакет и пакет с исходным кодом.
Настройка RPM доступна через файл /etc/rpmrc. Пример
выглядит подобно:
require_vendor: 1
distribution: I roll my own!
require_distribution: 1
topdir: /usr/src/me
vendor: Mickiesoft
packager: Mickeysoft Packaging Account <packages@mickiesoft.com>
optflags: i386 -O2 -m486 -fno-strength-reduce
optflags: alpha -O2
optflags: sparc -O2
signature: pgp
pgp_name: Mickeysoft Packaging Account
pgp_path: /home/packages/.pgp
tmppath: /usr/tmp
Строка require_vendor заставляет RPM найти строку
производителя. Она может быть из файла /etc/rpmrc или из
заголовка самого spec-файла. Что выключить эту опцию, смените число
на 0. Тоже самое является правдой для строк
require_distribution и require_group.
Следующая строка это строка distribution. Вы можете
определить ее здесь или позже в заголовке spec-файла. При
построении пакета для особого дистрибутива это хорошая идея
убедиться что строка правильна, даже хотя она требуется.
Строка vendor обозначает тоже самое, но может быть чем
угодно (например, Joe's Software and Rock Music Emporium).
RPM также сейчас поддержку для построения пакетов для множественных
архитектур. Файл rpmrc может содержать переменную ``optflags''
для построения вещей, которые требуют специфических для данной
архитектуры флагов для построения. Смотрите следующие разделы для
описания как использовать эту переменную.
В добавление к вышеприведенным макросам, существует еще несколько. Вы можете использовать:
rpm --showrc
Мы начнем с обсуждения spec-файла. Spec-файл требуется для построения пакета. Spec-файл это описание программного обеспечения вместе с инструкциями как построить пакет и списком файлов для всех устанавливаемых файлов.
Вы можете захотеть назвать ваш spec-файл согласно стандартному соглашению. Имя должно быть следующим: имя пакета-тире-номер версии-тире-номер выпуска (релиз)-точка-spec.
Здесь приведен маленький spec-файл (vim-3.0-1.spec):
Summary: ejects ejectable media and controls auto ejection
Name: eject
Version: 1.4
Release: 3
Copyright: GPL
Group: Utilities/System
Source: sunsite.unc.edu:/pub/Linux/utils/disk-management/eject-1.4.tar.gz
Patch: eject-1.4-make.patch
Patch1: eject-1.4-jaz.patch
%description
This program allows the user to eject media that is autoejecting like
CD-ROMs, Jaz and Zip drives, and floppy drives on SPARC machines.
%prep
%setup
%patch -p1
%patch1 -p1
%build
make RPM_OPT_FLAGS="$RPM_OPT_FLAGS"
%install
install -s -m 755 -o 0 -g 0 eject /usr/bin/eject
install -m 644 -o 0 -g 0 eject.1 /usr/man/man1
%files
%doc README COPYING ChangeLog
/usr/bin/eject
/usr/man/man1/eject.1
Заголовок имеет несколько стандартных полей, которые вам необходимо заполнить. Также существует несколько предостережений. Поля должны быть заполнены как показано:
Summary: Это однострочное описание пакета.
Name: Это должна быт строка имени из имени файла rpm,
котрое вы планируете использовать.
Version: Это должна быть строка версии из имени файла
rpm, которое вы планируете использовать.
Release: Это номер выпуска для пакета с той же самой
версией (например, если мы сделали пакет и обнаружили, что он
незначительно неисправный и нам необходимо сделать его заново, то
следующий пакет будет номер выпуска 2).
Icon: Это имя файла иконки, которое будет использоваться
другими высокоуровневыми утилитами установки (подобными ``glint''
из Red Hat). Она должна быть в формате gif и располагаться в
директории SOURCES.
Source: Эта строка указывает на расположение "ДОМА"
файла исходных текстов. Она используется если вы хотите получить
исходные тексты снова и проверить новые версии. Предостережение: Имя
файла в этой строке ДОЛЖНО соответствовать имени файла который вы
имеете на своей собственной системе (например не изменяйте имя
загруженного файла исходных текстов). Вы можете также указать
больше чем один файл исходных текстов используя следующие строки:
Source0: blah-0.tar.gz
Source1: blah-1.tar.gz
Source2: fooblah.tar.gz
SOURCES. (Структура
директорий обсуждается далее в разделе "Дерево директорий исходных
текстов").
Patch: Это место где вы можете найти заплатки, если вы
захотите загрузить их снова. Предостережение: Имя файла должно
соответствовать имени файла которое вы использовали когда делали
вашу заплатку. Вы можете также заметить, что вы можете иметь много
файлов заплаток также как вы можете иметь много файлов исходных
текстов. У вас должно быть что-то подобное:
Patch0: blah-0.patch
Patch1: blah-1.patch
Patch2: fooblah.patch
SOURCES.
Copyright: Эта строка говорит с какими авторскими
правами идет пакет. Вы можете использовать что-то подобное GPL,
BSD, MIT, public domain, distributable, или commercial.
BuildRoot: Эта строка позволяет вам указать директорию
как ``корневую'' для построения и установки нового пакета. Вы
можете использовать это для тестирования вашего пакета до установки
его на вашей машине.
Group: Эта строка используется чтобы указать
высокоуровневым программам установки (таким как ``glint'' Red Hat)
где разместить эту отдельную программу в их иерархических
структурах. Дерево груп в настоящее время выглядит примерно так:
Applications
Communications
Editors
Emacs
Engineering
Spreadsheets
Databases
Graphics
Networking
Mail
Math
News
Publishing
TeX
Base
Kernel
Utilities
Archiving
Console
File
System
Terminal
Text
Daemons
Documentation
X11
XFree86
Servers
Applications
Graphics
Networking
Games
Strategy
Video
Amusements
Utilities
Libraries
Window Managers
Libraries
Networking
Admin
Daemons
News
Utilities
Development
Debuggers
Libraries
Libc
Languages
Fortran
Tcl
Building
Version Control
Tools
Shells
Games
%description В действительности это не часть заголовка,
но этот раздел должен быть описан вместе с остальными частями
заголовка. Вам нужен один таг описания на один пакет и/или
подпакет. Это многостроковое поле, которое должно использоваться
чтобы дать достаточно полное описание пакета.
Это второй раздел в spec-файле. Он используется чтобы сделать
исходные тексты готовыми к построению. Здесь вам необходимо сделать
все что угодно чтобы сделать исправления в исходных текстах и
сделать настройку подобную той, которую необходимо сделать чтобы
выполнить make.
Одно замечание: Каждый из этих разделов в действительности
просто место для выполнения скриптов оболочки. Вы должны просто
сделать sh-скрипт и поместить его после тага %prep
для распаковки и исправления ваших исходных текстов. Однако мы
добавили макросы чтобы помочь вам сделать это.
Первый из этих макросов это макрос %setup. В своей
простейшей форме (без командной строки), он просто распаковывает
исходные тексты и делает cd в директорию исходных текстов. Он
также принимает следующие опции:
-n name установит имя директории где будет производиться
построение пакета в name. Значение по умолчанию равно
$NAME-$VERSION. Другие возможные значения
включают $NAME, ${NAME}${VERSION},
или что использует главный файл архива. (Заметим, что эти
переменные с ``$'' не являются настоящими переменными
доступными внутри spec-файла. Они просто используются здесь вместо
имен примеров. Вам необходимо использовать настоящие имена и версии
в вашем пакете, а не эти переменные).
-c создаст указанную директорию до выполнения
распаковки архивов.
-b # будет выполнять распаковку Source# до
выполнения cd в директорию (и это делает нечувствительной к опции
-c так что не делайте ее). Это полезно только в случае
множества файлов исходных текстов.
-a # будет выполнять распаковку Source#
после перехода в директорию.
-T Эта опция отменяет действия по умолчанию при
распаковке исходных текстов и требует опций -b 0 или -a 0
чтобы произвести разархивацию главного файла исходных текстов. Вам
нужно это в случае наличия дополнительных файлов исходных текстов.
-D Не удалять директорию до распаковки. Это полезно
только когда вы имеете больше одного макроса setup. Эта опция
должна использоваться только в макросах setup после
первого (но никогда не быть в первом макросе).
Следующий из имеющихся макросов это макрос %patch. Этот
макрос помогает автоматизировать процесс наложения заплаток на
исходные тексты. Макрос имеет несколько опций, перечисленных ниже:
# будет прикладывать Patch# как файл заплатки.
-p # указывает количество отбрасываемых директорий
для команды patch(1).
-P Действие по умолчанию -- наложение Patch (или
Patch0). Этот флаг запрещает действие по умолчанию и будет
требовать 0 чтобы распаковать главный файл с исходными
текстами. Эта опция полезна во второй (и последующих) макросах
%patch, которые требуют номера отличного от номера в
первом макросе.
%patch# вместо
выполнения команды: %patch # -P
Это все макросы которые вам необходимы. После того как вы все
сделаете правильно, вы также можете сделать любую другую настройку,
которая необходима, используя скрипты на sh. Все что вы
включите до макроса %build (обсуждаемого в следующем
разделе) выполняется через sh. Посмотрите в вышеприведенном
разделе для того чтобы увидеть какие вещи вы можете сделать если
захотите.
Для этого раздела нет никаких макросов. Вы должны просто
поместить здесь любые команды которые вам необходимо выполнить для
построения программного обеспечения после того как вы распаковали
исходные тексты, изменили их с помощью заплаток и вошли в
директорию. Это просто другой набор команд передаваемых sh,
так что любые команды sh могут быть здесь (включая
комментарии) Ваша текущая директория устанавливается в каждом
из этих разделов в корневую директорию для исходных текстов, так
что помните это. Вы можете переходить в поддиректории если это
необходимо.
В этом разделе также нет никаких макросов. Вам просто необходимо
поместить команды необходимые для установки. Если для вашего пакета
существует команда make install, то просто поместите ее здесь.
Если ее нет, то вы можете сделать заплатку для makefile, чтобы
выполнялась команда make install и просто делать здесь
make install, или вы можете вручную устанавливать пакет с
помощью команд sh. Вы можете считать свою текущую директорию
как корневую директорию для исходных текстов пакета.
Вы можете поместить скрипты которые запустятся до и после
инсталляции и деинсталляции двоичного пакета. Основная причина для
этого -- это выполнение вещей подобных запуску ldconfig
после установки или удаления пакета, который содержит разделяемые
библиотеки. Макросы для каждого из скриптов приведены как показано:
%pre макрос для выполнения предустановочного
скрипта.
%post макрос для выполнения послеустановочного
скрипта.
%preun макрос для выполнения скрипта перед
удалением пакета.
%postun макрос для скрипта выполняемого после
удаления пакета.
Содержимым разделов должны быть любые sh скрипты, хотя вам
не нужно определять строку #!/bin/sh.
Это раздел где вы должны перечислить файлы для двоичного
пакета. У RPM нет способа узнать какие двоичные файлы установлены
как результат выполнения make install. НЕ существует
способа сделать это. Некоторые предлагают выполнить команду
find до и после установки пакета. На многопользовательской
системе это неприемлемо так как другие файлы могут быть созданы в
течении процесса построения пакета, которые не имеют ничего общего
с самим пакетом.
Есть несколько доступных макросов для выполнения специальных действий. Они перечислены и описаны здесь:
%doc используется для обозначения документации в
исходных текстах пакета, которую вы хотите установить при
установке. Документы будут установлены в директорию
/usr/doc/$NAME-$VERSION-$RELEASE. Вы
можете перечислить много документов в командной строке этого
макроса или вы можете перечислить все отдельно, используя этот
макрос для каждого документа.
%config используется для обозначения
конфигурационных файлов в пакете. Этот список включает файлы
подобные sendmail.cf, passwd, и т.п. Если вы позже удаляете пакет
содержащий конфигурационные файлы, все неизмененные файлы будут
удалены и все измененные будут переименованы со старыми названиями с
добавлением .rpmsave к имени файла. Вы можете перечислять
много файлов в этом макросе.
%dir обозначает единичную директорию в списке
файлов включенную как директория которой владеет пакет. По
умолчанию, если вы укажете имя директории БЕЗ макроса
%dir, то ВСЕ в этой директории будет включено в
список файлов и позже установлено как часть пакета.
%files -f <filename> позволит вам
перечислить ваши файлы в некотором файле внутри директории
построения исходных текстов. Это просто великолепно в случае когда
у вас пакет, который может построить свой собственный список
файлов. Затем вы просто включаете этот список файлов здесь и вы не
должны специально перечислять файлы.
Наибольшое предостережение в списке файлов это перечисление
директорий. Если вы случайно укажете /usr/bin, то ваш
двоичный пакет будет содержать все файлы в директории
/usr/bin на вашей системе.
Первая вещь которая вам необходима -- это правильно настроенное
дерево построения. Это настраивается используя файл
/etc/rpmrc. Большинство людей просто используют директорию
/usr/src.
Вам надо создать следующие директории чтобы создать дерево построения:
BUILD это директория где происходят все построения с
помощью RPM. Вы не должны проводить ваше тестовое построение где то
в особом месте, но это место где RPM будет проводить построение
пакета.
SOURCES это директория где вы должны поместить ваши
оригинальные архивные файлы и ваши заплатки. Это место где RPM
будет искать их по умолчанию.
SPECS это директория где должны находиться все spec-файлы.
RPMS это место где RPM поместит все двоичные пакеты RPM
после их построения.
SRPMS место где будут помещены пакеты RPM с исходными текстами.
Первая вещь которую вы вероятно захотите сделать -- это
построить исходные тексты без использования RPM. Чтобы сделать это
распакуйте исходные тексты и измените имя директории на
$NAME.orig. Затем еще раз распакуйте исходные тексты.
Используйте эти исходные тексты для построения. Перейдите в
директорию исходных текстов и следуйте инструкциям по их
построению. Если вы что-то редактировали вам необходимо сделать
заплатку. После того как вы построили исходные тексты, очистите
директорию исходных текстов. Убедитесь что вы удалили все файлы
созданные скриптом configure. Затем перейдите из директории
исходных текстов в директорию являющуюся для них родительской.
Затем сделайте что-то подобное:
diff -uNr dirname.orig dirname > ../SOURCES/dirname-linux.patch
Это создаст для вас заплатку, которую вы сможете использовать в вашем spec-файле. Заметим что ``linux'', который вы видите в имени заплатки это просто идентификатор. Вы можете захотеть использовать что-нибудь более описательное как ``config'' или ``bugs'' для описания почему вы сделали эту заплатку. Также хорошая идея посмотреть в файл заплатки, который вы создали, до его использования чтобы убедиться что бинарные файлы случайно не включены.
Сейчас у вас есть исходные тексты, которые будут строиться и вы знаете как построить и установить их. Посмотрите в вывод установочной последовательности и постройте на его основе список ваших файлов для использования в spec-файле. Мы обычно создаем spec-файл параллельно со всеми описанными шагами. Вы можете сначала создать его и заполнить самые легкие его части, а затем затем заполнять его по мере прохождения всех этапов.
Когда вы имеете spec-файл, вы готовы попытаться и построить ваш пакет. Наиболее полезный способ сделать это -- использовать команду похожую на следующую:
rpm -ba foobar-1.0.spec
Также существуют другие опции полезные с переключателем -b:
p обозначает просто запуск раздела prep spec-файла.
l это проверка списка, который делает некоторые проверки
раздела %files.
c выполняет раздел prep и компиляцию. Это полезно в
случае, когда вы не уверены будут ли ваши исходные тексты
построены. Это выглядит бесполезно, потому-что вы можете захотеть
просто самому поиграть с исходными текстами до их построения и
затем начать использовать RPM, но когда вы привыкнете использовать
RPM вы найдете случаи когда этот ключ используется.
i выполняет prep, компиляцию и установку.
b выполняет prep, компиляцию, установку, и построения
двоичного пакета.
a строит все (и двоичный пакет и пакет с исходными текстами).Существует несколько модификаторов к переключателю -b. Это:
--short-circuit будет пропускать действия до указанной
стадии (может использоваться с ключами c и i).
--clean удаляет дерево построения когда все сделано.
--keep-temps будет сохранять все временные файлы и
скрипты которые созданы в /tmp. Вы можете в действительности
посмотреть какие файлы созданы в директории /tmp используя опцию
-v.
--test не выполняет никакую реальную стадию, но делает keep-temp.
После того как вы построили двоичный пакет и пакет с исходным
кодом, вам необходимо проверить их. Самый легкий и наилучший способ
--- это использовать для тестирования использовать другою машину, а
не ту на которой вы создавали пакет. После всего вам только лишь
надо выполнить несколько команд make install на вашей машине,
так что все должно быть установлено.
Вы можете выполнить rpm -u packagename для тестирования
пакета, но это может быть обманывающим потому-что в процессе
построения пакета вы делали make install. Если вы пропустите
что-нибудь в своем списке файлов, это не будет удалено при
инсталляции. Если вы затем будете переставлять двоичный пакет, то
все на вашей системе будет в норме, но сам пакет не будет полным.
Будьте уверенными и помните, что если вы делали rpm -ba
package, то большинство людей будут устанавливать ваш пакет
выполняя лишь команду rpm -i package. Будьте уверены, что вы
не делаете ничего в разделах build или install, что
должно будет быть сделано при установке только двоичного пакета.
После того как вы сделали свой собственный пакет RPM из чего-либо (предполагая что этого еще нет в виде RPM) вы можете предлагать свою работу другим людям (также предполагая, что ваш RPM свободно распространяемый). Чтобы сделать это вы можете захотеть загрузить пакет на сервер ftp.redhat.com.
Пожалуйста смотрите выше разделы "Тестирование пакета" и "Что делать с вашим новым пакетом RPM". Мы хотим сделать доступными все пакеты RPM которые мы можем получить и хотим чтобы это были хорошо сделанные пакеты. Пожалуйста найдите время для хорошего тестирования пакетов и найдите время для их загрузки для общей выгоды. Также пожалуйста будьте уверены, что вы загружаете только свободно распространяемое программное обеспечение. Коммерческое программное обеспечение и shareware не должны быть загружены до тех пор пока не будут иметь авторские права, которые определенно констатируют что это разрешено. Это включает программное обеспечение Netscape, ssh, pgp, и т.п.