*.RPM - файлы, аналогичны SFX-архивам Windows и программам-инсталляторам.
Как правило, содержат в себе собранные исходные тексты программ, которые легко поддаются редактированию.
Исходный код самого пакета по команде пользователя собирается с расширением.SRPM.

Операции с пакетами из консоли производится командой RPM.
Напоминаю:
справку по ней можно получить, набрав "rpm --help" или "rpm -?"; а подробный мануал - "man rpm"
(чтобы выйти из мануала и вернуться в терминал, нужно нажать "q" ).

Здесь предложено ознакомиться сначала с описанием самих программ по установке пакетов
(главная из них - rpm), а затем - со списком команд и параметров для этой программы.

В операционной системе Linux существуют три способа установки программного обеспечения:

• Традиционный.
• Из пакетов RPM.
• Из пакетов, содержащих исходный код.

Рассмотрим по порядку все три способа.

Этот способ заключается в том, что программа распространяется не в собранном виде, а в виде исходных текстов. Данный способ называется традиционным, потому что он был первым способом установки программ до появления менеджера RPM или аналогичных ему (apt-get).

Как правило, исходный текст распространяется в архиве. Обычно файл, содержащий исходный текст, имеет двойное расширение: например, tar.gz или tar.bz2. Это означает, что данный файл сжат двумя архиваторами: сначала tar, а потом gzip.

Распаковывать архив нужно по принципу стека: сначала внешним архиватором, а потом внутренним. Предположим, что prg-2.00.tar.gz - это имя файла нашего архива. Для его распаковки нужно ввести команды:

gunzip prg-2.00.tar.gz
tar xvf prg-2.00.tar

Первая команда распакует файл prg-2.00.tar, который мы укажем в качестве одного их аргументов во второй команде. Параметр х программы tar означает, что нам нужно выполнить извлечение файлов из архива (параметр с - создание). Параметр v можете указывать по собственному усмотрению, он обеспечивает большую информативность при работе программы.
Последний параметр f является обязательным при работе с файлами.
Первоначально программа tar была предназначена для работы с пленками стримеров, поэтому нужно использовать параметр f, чтобы сказать программе, что нам нужно работать с файлами.
Если внешнее расширение не gz, a bz или bz2, то вместо первой команды вам нужно ввести команды (соответственно):

bunzip prg-2.00.tar.bz
bunzip2 prg-2.00.tar.bz2

Затем, как и в первом случае, нужно выполнить команду tar (с такими же параметрами).

Иногда файлы исходных текстов имеют всего одно расширение tgz. В этом случае вам нужно ввести всего одну команду:

tar xzf prg-2.00.tgz

Параметр z означает извлечение файлов с использованием распаковщика gzunzip. Обычно такое расширение имеют файлы архивов, созданные с помощью программы tar и пропущенные через фильтр архиватора gzip.

Следующий этап - это непосредственная установка программы. После успешного завершения первого этапа(распаковки) перейдите в каталог, содержащий исходные тексты. Обычно это каталог <имя_программы-версия>:

cd prg-2.00

. /configure
make
make install

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

Обычно такое случается, когда в вашей системе не установлена одна из необходимых новой программе библиотек. Для продолжения установки необходимо установить требуемую библиотеку и попытаться заново ввести команду./configure. После успешного завершения работы программы./configure будет создан файл Makefile, в котором будут указаны необходимые параметры (пути к библиотекам, путь для установки программы) для программы make.

Вторая команда (make) «собирает» программу. На этом этапе программа компилируется, то есть создаются бинарные исполнимые файлы из исходных текстов.

Третья команда - make install - устанавливает программу и файлы справочной системы в соответствующие каталоги. Обычно программы устанавливаются в каталог /usr/bin, но это зависит от содержимого конфигурационного файла Makefile.

После успешной установки программы вы можете ее запустить, предварительно прочитав документацию по этой программе.

Установка программного обеспечения в дистрибутивах Red Hat и Mandrake производится с помощью программы rpm. RPM (Red Hat Package Manager) - это менеджер пакетов Red Hat. Несмотря на то, что в названии присутствует «Red Hat», он полностью предназначен работать как открытая пакетная система, доступная для использования кем угодно. Она позволяет пользователям брать исходный код для нового программного обеспечения и упаковывать его в форме исходного и двоичного кода, так что двоичные файлы могут быть легко установлены и отслежены, а исходный код легко
построен. Эта система также сопровождает базу данных всех пакетов и их файлов, что может быть использовано для проверки пакетов и запроса информации о файлах и/или пакетах.

В отличие от привычных мастеров InstallShield, которые используются для установки программ для Windows, пакеты RPM (файлы с расширением.rpm) не являются выполняемыми файлами, то есть программами. В пакетах содержатся файлы (как в архиве), которые нужно установить, а также различная информация об этом пакете: какой пакет необходим для работы этого пакета, с каким пакетом конфликтует, информация о разработчике, а также информация, указывающая, какие действия нужно выполнять при установке этого пакета, например, какие каталоги нужно создать. Менеджер пакетов RPM используется во многих дистрибутивах Linux (Red Hat, Mandrake, ASP, Black Cat) и является довольно легкой и гибкой в использовании системой, что обусловливает его популярность.

Например, для пакета software-1.0-I.i386.rpm имеют место: software - название;

1.0 - версия программы;
1 - выпуск пакета;
i386 - платформа Intel 386.

Обычно в имени файла пакета указываются его название, версия, выпуск, платформа. Последние четыре символа - «.rpm» - признак того, что данный файл является пакетом. В Linux отсутствует такое понятие как расширение или тип файла.

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

С названием и версией программы, я думаю, все ясно. А вот с архитектурой немного сложнее. Самыми «универсальными» пакетами являются пакеты, рассчитанные на архитектуру Intel 386. Данная программа должна
работать на любом процессоре Intel, начиная с 80386DX (или совместимого с ним). А вот если у вас процессор 80486, пакет, рассчитанный для работы с архитектурой 80586 (Pentium), скорее всего, не установится в вашей системе.
Обычно для процессоров архитектуры CISC (с набором команд х86) используются следующие обозначения:

i386 - Intel 80368DX;
i586 - Intel Pentium (MMX), AMD K5 (K6);
i686 - Intel PPro, Celeron, PII, РШ, PIV.

В простейшем случае команда установки пакета выглядит так:

rpm -i <пакет>

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

Если нужен дополнительный пакет, просто установите его. А вот если программа конфликтует с уже установленным пакетом, то вам нужно будет выбрать, какой пакет вам больше нужен: уже установленный или новый.

При установке программы я рекомендую указывать два дополнительных параметра: h и v. Первый указывает программе вывести полоску состояния процесса установки, а второй выводит дополнительные сообщения. Полоска состояния будет отображена в виде символов #. Учитывая эти два параметра, команда установки немного усложнится:

rpm -ihv software-1.0-1.i386.rpm

Установку можно производить не только с локального диска, но и по протоколу FTP:

Для удаления пакета используется команда:

rpm -e <пакет>

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

Для пропуска проверки зависимостей нужно использовать параметр --nodeps.
Это бывает иногда полезно. Например, у вас установлена программа postfix, а вам нужно установить программу sendmail. Обе программы используются для отправки почты.

Однако для работы многих почтовых программ необходим агент МТА (Mail Transfer Agent) - программа для отправки почты (postfix или sendmail).
Поэтому с помощью параметра -е удалить программу postfix вы не сможете.
Установить программу sendmail без удаления программы postfix вы также не сможете, потому что пакеты конфликтуют друг с другом. В этом случае вам поможет команда:

rpm -e -nodeps postfix

После такого удаления нормальная работа других программ, которым необходим МТА, невозможна, поэтому вам сразу же нужно установить программу sendmail (или другой МТА). Устанавливать программу в таком случае нужно, как обычно, с помощью параметра -i.

Для обновления программ используется параметр -U. Я рекомендую использовать его и при установке программ, потому что, если устанавливаемый пакет уже был установлен, то будет произведено его обновление, а если нет, то будет просто установлен новый пакет. Для того, чтобы видеть текстовый индикатор при установке пакетов, используйте опцию h. Команда для обновления пакета:

rpm -Uhv <пакет>

Например:

rpm -Uhv software-1.1-4.i386.rpm

Текстовый индикатор будет отображен в виде символов #. Просмотреть все установленные пакеты можно с помощью команды:

rpm -qa I less

Если вам требуется узнать, установлен ли определенный пакет, выполните команду:

rpm -qa | grep название_пакета

Просмотреть общую информацию о пакете можно с помощью команды:

rpm -qi пакет

а информацию о файлах, которые входят в состав пакета:

rpm -ql пакет

Менеджер пакетов RPM является мощным средством для произведения операций над пакетами - создания, установкя, обновления, удаления. Однако интерфейс командной строки может понравиться далеко не всем, а особенно начинающему администратору. Существуют и графические (под X Window) реализации менеджера пакетов - например, kpackage из KDE, gnorpm и другие.
Я рекомендую использовать программу gnorpm, которая обладает интуитивным графическим интерфейсом. RPM больше подходит для создания новых пакетов, а также для обновления большого числа пакетов. Для установки одного-двух пакетов лучше и удобнее использовать gnorpm.

Функции программы gnorpm:

Установка пакетов.
Удаление пакетов.
Получения сведений о пакете.
Проверка пакета.
Поиск пакета в базе RPM.

Для установки какого-либо пакета нажмите на кнопку «Установить». Если в приводе CD-ROM находится инсталляционный CD, то в появившемся окне вы увидите список еще не установленных в системе пакетов.

Если пакета нет в списке или вы хотите установить пакет, который не входит в состав дистрибутива, нажмите на кнопку «Добавить» и добавьте в список пакеты, которые вы хотите установить. Нажмите на кнопку «Запрос» для получения сведений о пакете.

Если пакет еще не установлен и у вас достаточно места на диске для его установки, нажмите на кнопку «Установка». После этого будет выполнена проверка пакета на предмет удовлетворения зависимостей: не требует ли этот пакет наличия какого-нибудь неустановленного пакета и не конфликтует ли он с уже установленными пакетами. Если все в порядке, вы увидите окно состояния установки пакета.

Найти пакет вы можете с помощью операции Поиск. Для этого нажмите на кнопку «Поиск» на панели инструментов gnorpm или выполните команду меню Операции -> Поиск. В открывшемся окне вы можете установить критерии поиска и нажать на кнопку «Поиск».

В состав KDE входит программа с графическим интерфейсом пользователя, управляющая пакетами - kpackage. По своим функциям она аналогична программе gnorpm. Какую из этих программ использовать - дело вкуса и привычки.

Также стоит упомянуть о программе APT. Программа APT - это система управления пакетами программного обеспечения. Первоначально система APT была разработана для Debian Linux. Сейчас входит в состав некоторых Red Hat совместимых
дистрибутивов (например, apt-get и входит в состав AltLinux, но ее вы не найдете в Red Hat Linux). Для управления пакетами используется программа apt-get. Формат вызова программы apt-get такой:

apt-get [опции] [команды] [пакет. . .]

В дистрибутив Linux Mandrake входит собственное средство управления пакетами - rpmdrake. К десятой версии дистрибутива оно немного видоизменилось. Теперь оно состоит из трех частей:

/usr/sbin/edit-urpm-media - менеджер источников пакетов (что такое источники, я уже сказал, поэтому останавливаться на этом не будем);
rpmdrake - менеджер установки пакетов;
rpmdrake-remove - менеджер удаления пакетов.
Запустить любую из частей можно из меню К: Система| Настройка | Пакеты.

Иногда в пакетах RPM находятся не откомпилированные версии программ, а их исходный код. Признаком этого является слово src вместо названия архитектуры. Для установки такого пакета введите:

rpm --rebuild software-2.00-1.src.rpm

Разумеется, вместо software-2.00-l.src.rpm нужно указать реальное имя файла. Перед установкой программы ее исходный текст будет откомпилирован, и потом программа будет установлена.

ОБЩИЕ ОПЦИИ.

Эти опции могут быть использованы во всех режимах работы.

"-vv" Выводить много отладочной информации.

"--quiet" Выводить как можно меньше сообщений - как правило, выводятся только сообщения об ошибках.

"--help" Вывести более детальную, чем обычно, справку об использовании rpm.

"--version" Вывести одну строку, содержащую номер версии используемого rpm.

"--rcfile <список-файлов>" Каждый из файлов из разделенного двоеточиями <списка-файлов> последовательно читается rpm на предмет конфигурационной информации.
По умолчанию <список-файлов> выглядит как /usr/lib/rpm/rpmrc:/etc/rpmrc:~/.rpmrc.
В этом списке обязана существовать только первая строка; все тильды будут заменены значением $HOME.

"--root <каталог>" Использовать для всех операций файловую систему с корнем в <каталог>.
Обратите внимание, что это значит, что база данных также будет читаться и модифицироваться под <каталог>,и все pre и post скрипты будут исполняться после chroot() в <каталог>.

"--dbpath <путь>" Использовать базу данных RPM в <путь>.

"--justdb" Обновить только базу данных, не файловую систему.

"--ftpproxy , --httpproxy " Использовать как FTP или HTTP прокси.

"--ftpport <порт>, --httpport <порт>" Использовать <порт> как FTP или HTTP порт прокси-сервера.

"--pipe " Перенаправляет вывод rpm на вход команды .

Обслуживание базы данных:

rpm -i [--initdb]

rpm -i [--rebuilddb]

ОПЦИИ ПЕРЕСТРОЕНИЯ БАЗЫ ДАННЫХ.

Общая форма команды перестроения базы данных RPM выглядит так:
rpm --rebuilddb
Для построения новой базы данных:
rpm --initdb
Этот режим поддерживает только две опции, --dbpath и --root.

Запуск
rpm --showrc
выводит значения, которые rpm будет использовать для всех опций, которыемогут быть установлены в файлах rpmrc.

Сборка:
rpm [-b|t] +
rpm [--rebuild] +
rpm [--tarbuild] +

ОПЦИИ СБОРКИ (ПОСТРОЕНИЯ) ПАКЕТОВ.

Общая форма команды построения пакета rpm выглядит так:
rpm -O [опции-сборки] +
Аргумент -bfR применяется в том случае, если для сборки пакета используется spec-файл. Если же rpmfR должен извлечь этот файл из архива gzip (или compress), используется аргумент -tfR. После первого аргумента указывается следующий (OfR), указывающий какие этапы сборки и упаковки должны быть выполнены. Это один из:

"-bp" Исполнить стадию "%prep" spec-файла. Обычно это включает в себя распаковку исходников и прикладывание к ним патчей.

"-bl" Произвести "list check". В секции "%files" spec-файла производится расширение макросов и проверка перечисленных файлов на существование.

"-bc" Исполнить стадию "%build" spec-файла (предварительно исполнив стадию %prep). Обычно это сводится к исполнению некого эквивалента "make".

"-bi" Исполнить стадию "%install" spec-файла (предварительно исполнив стадии %prep и %build). Обычно это сводится к исполнению некого эквивалента
"make install".

"-bb" Собрать бинарный пакет (предварительно исполнив стадии %prep, %build и %install).

"-bs" Собрать только исходный пакет (предварительно исполнив стадии %prep, %build и %install).

"-ba" Собрать бинарный (RPM) и исходный (SRPM) пакеты (предварительно исполнив стадии %prep, %build и %install).

Также могут быть использованы следующие опции:

"--short-circuit" Исполнить непосредственно указанную стадию, пропустив предшествующие. Может быть использована только с -bc и -bi.

"--timecheck" Установить возраст для "timecheck" (0 чтобы запретить). Это значение также может быть установлено путем определения макроса "_timecheck".
Значение timecheck определяет максимальный возраст (в секундах) пакуемых в пакет файлов. Для всех файлов, которые старше этоговозраста, будет выводиться предупреждение.

"--clean" Удалить дерево, использованное для сборки, после того, как построены пакеты.

"--rmsource" Удалить исходники и spec-файл после сборки (может быть использовано отдельно, например "rpm --rmsource foo.spec").

"--test" Не исполнять никаких стадий сборки. Полезно для тестирования spec-файлов.

"--sign" Встроить в пакет PGP-подпись. Эта подпись может быть использована для проверки целостности и источника происхождения пакета. См. секцию
ПОДПИСИ PGP на предмет опций PGP.

"--builroot <каталог>" Использовать каталог <каталог> как корневой для сборки пакетов.

"--target <платформа>" При сборке пакета интерпретировать <платформа> как arch-vendor-os
и соответственно установить макросы _target, _target_arch и _target_os.

"--buildarch " Собрать пакет для архитектуры не обращая внимания на архитектуру
системы, на которой производится сборка. Эта опция устарела, в RPM 3.0 вместо нее следует использовать опцию --target.

"--buildos " Собрать пакет для операционной системы не обращая внимания на
архитектуру системы, на которой производится сборка. Эта опция устарела, в RPM 3.0 вместо нее следует использовать опцию --target.

ОПЦИИ ПЕРЕСБОРКИ И ПЕРЕКОМПИЛЛЯЦИИ.

Существуют еще два способа запуска rpm:

rpm --recompile <файл_исходного_пакета>+"

rpm --rebuild <файл_исходного_пакета>+"

Будучи вызванным таким способом, rpm устанавливает указанный исходный пакет и исполняет %prep, %build и %install. Кроме того, --rebuild собирает новый бинарный пакет. После того, как сборка закончена, удаляется дерево, использованное для сборки (как с опцией --clean), сами исходники и spec-файл.

ПОДПИСЬ СУЩЕСТВУЮЩЕГО RPM.

rpm --resign <файл_бинарного_пакета>+ Эта опция генерирует и вставляет новые подписи в указанные пакеты.
Все существующие подписи из пакетов удаляются.

rpm --addsign <файл_бинарного_пакета>+ Эта опция генерирует и добавляет новые подписи в указанные пакеты.
Все существующие подписи пакетов при этом сохраняются.

ПОДПИСИ PGP.

Для того, чтобы использовать возможность подписи, rpm должен быть настроен для запуска PGP и должен быть способен найти public key ring с ключом RPM в нем. По умолчанию rpm для поиска keyrings использует умолчания PGP (соблюдая PGPPATH).
Если ваlи key rings расположены не там, где их ожидает найти PGP, вы должны настроить макрос "_pgp_path" на каталог, содержащий ваlи key rings.

Если вы хотите иметь возможность подписи создаваемых вами пакетов, вам также необходимо создать свою собственную пару из публичного и секретного ключей (см. документацию PGP). Кроме выlеупомянутого макроса, вам также необходимо настроить макросы

"_signature" Тип подписи. В настоящее время поддерживается только pgp.

"_pgp_name" Имя "пользователя" , чьи ключи вы хотите использовать для подписи ваших пакетов.

При сборке пакетов вы добавляете к командной строке опцию --sign. У вас спросят пароль и ваш пакет будет собран и подписан.

Например, для того чтобы использовать PGP для подписи пакетов от имени пользователя "John Doe " из key rings, находящихся в /etc/rpm/.pgp, вы должны включить

"%_signature"
pgp
"%_pgp_name"
/etc/rpm/.pgp
"%_pgp_name"
John Doe "

В файл конфигурации макросов. Используйте /etc/rpm/macros для общесистемной и ~/.rpmmacros для пользовательской конфигурации.

Обслуживание установленных пакетов:

rpm [--install] [опции-установки] [файл-пакета]+
rpm [--eshen|-F] [опции-установки] [файл-пакета]+
rpm [--uninstall|-e] [опции-удаления] [пакет]+
rpm [--verify|-V] [опции-верификации] [пакет]+

ОПЦИИ УСТАНОВКИ И ОБНОВЛЕНИЯ.

Общая форма команды установки rpm выглядит так:
rpm -i [опции-установки] <файл_пакета>+
Такая команда устанавливает новые пакеты.

Общая форма команды обновления rpm выглядит так:
rpm -U [опции-установки] <файл_пакета>+
Такая команда производит обновление установленных пакетов. Работа этой команды полностью аналогична работе команды установки за исключением того, что все остальные версии пакетов удаляются из системы.

rpm [-F|--eshen] [опции-установки] <файл_пакета>+
Такая команда производит обновление пакетов, но только если в системе существуют более ранние версии этих пакетов.
Допускается задание <файл_пакета> в виде ftp или http style URL. В этом случае перед установкой файл будет получен с cервера, указанного в URL.

"--force" То же, что и комбинация --replacepkgs, --replacefiles и --oldpackage.

"-h, --hash" Выводить 50 знаков "#" по мере распаковки архива с пакетом. Используется с -v для красивости.

"--oldpackage" Позволяет заменить новый пакет на более старый при обновлении (откатиться назад).

"--percent" Выводить процент готовности по мере распаковки архива с пакетом. Задумано для облегчения использования rpm из других утилит.

"--replacefiles" Устанавливать пакеты даже если они перепиlут файлы из других, уже установленных пакетов.

"--replacepkgs" Устанавливать пакеты даже если некоторые из них уже установлены в системе.

"--allfiles" Устанавливать или обновлять все файлы, определенные как "missingok", даже если они уже существуют.

"--nodeps" Не проверять зависимости перед установкой или обновлением пакета.

"--noscripts" Не исполнять пре- и постустановочных скриптов.

"--notriggers" Не исполнять триггер-скриптов, взведенных на установку данного пакета.

"--ignoresize" Не проверять файловую систему на наличие достаточного свободного места перед установкой этого пакета.

"--excludepath <путь>" Не устанавливать файлы, чьи имена начинаются с <путь>.

"--excludedocs" Не устанавливать никаких файлов, отмеченных как файлы документации (включает мануалы и документы texinfo).

"--includedocs" Устанавливать файлы документации. Это поведение по умолчанию.

"--test" Не устанавливать пакет, просто проверить возможность установки и сообщить о возможных проблемах.

"--ignorearch" Произвести установку или обновление даже если архитектуры бинарного RPM и машины не совпадают.

"--ignoreos" Произвести установку или обновление даже если операционные системы бинарного RPM и машины не совпадают.

"--prefix <путь>" Установить префикс установки в <путь> для переместимых пакетов.

"--relocate <старый_путь>=<новый_путь>" Для переместимых пакетов: преобразовывает файлы, которые должны были бы быть установлены в <старый_путь> в <новый_путь>.

"--badreloc" Для использования вместе с --relocate. Производит перемещение даже если пакет не переместимый.

"--noorder" Не переупорядочивать список устанавливаемых пакетов. Обычно список переупорядочивается для удовлетворения зависимостей.

Запрос:
rpm [--query] [опции-запроса]
rpm [--querytags]

ОПЦИИ ЗАПРОСА.

Общая форма команды запроса(инспекции) rpm выглядит так:
rpm -q [опции-запроса]
Можно задать формат, в котором будут выводиться информация о пакете. Для этого используется опция --queryformat с последующей строкой формата.

Форматы запроса представляют собой модифицированную версию стандартного форматирования printf(3). Формат состоит из статических строк (которые могут включать стандартные escape-последовательности C для переводов строки, табуляций и других специальных символов) и форматов по типу используемых в printf(3). Так как rpm уже знает типы данных, подлежащих выводу, спецификаторы типов должны быть опущены и заменены именами тэгов(ключей) хедеров, подлежащих выводу, заключенными в {}. Часть имени тэга RPMTAG_ может быть опущена.

Альтернативные форматы вывода могут быть заданы путем добавления к имени тэга:typetag. В настоящее время поддерживаютсяследующие типы: octal, date, shescape, perms, fflags и depflags.

Например, для вывода только названий запраlиваемых пакетов, можно использовать в качестве строки формата %{NAME}. Для вывода названий пакетов и информации о дистрибутиве в две колонки можно использовать %-30{NAME}%{DISTRIBUTION}.

Будучи запущенным с аргументом --querytags, rpm выведет список всех тэгов, о которых он знает.

Есть два набора опций для запроса - выбор пакетов и выбор информации.

Опции выбора пакетов:

"<название_пакета>" Запрос установленного пакета, называющегося <название_пакета>.

"-a, --all" Запрос всех установленных пакетов.

"--whatrequires " Запрос всех пакетов, требующих для правильного функционирования.

"--whatprovides " Запрос всех пакетов, предоставляющих сервис.

"-f <файл>, --file <файл>" Запрос пакета, которому принадлежит файл <файл>.

"-g <группа>, --group <группа>" Запрос пакетов из группы <группа>.

"-p <файл_пакета>" Запрос (неинсталлированого) пакета <файл_пакета>.
Файл <файл_пакета> может быть задан как ftp или http style URL; в этом случае хедер пакета будет получен с указанного сервера.

"--specfile " Разбор и запрос так, как если бы это был пакет. Хотя не вся информация (например, списки файлов) доступна, этот тип запроса позволяет использовать rpm для извлечения информации из spec-файлов без необходимости написания парсера spec-файлов.

"--querybynumber " Запросить непосредственно запись базы данных номер . Полезно для отладочных целей.

"--triggeredby <имя_пакета>" Запрос всех пакетов, содержащих триггер-скрипты, активизируемые пакетом <имя_пакета>.

Опции выбора информации:

"-i"
Выводит информацию о пакете, включая название, версию и описание. Использует --queryformat если таковой задан.

"-R, --requires" Выводит список пакетов, от которых зависит данный пакет.

"--provides" Выводит список сервисов и библиотек, предоставляемых данным пакетом.

"--changelog" Выводит протокол изменений данного пакета.

"-l, --list" Выводит список файлов, входящих в данный пакет.

"-s, --state" Выводит состояние файлов в пакете (подразумевает -l).

Каждый файл может находиться в одном из следующих состояний: нормальный, не установлен или заменен.

"-d, --docfiles" Вывести список только файлов документации (подразумевает -l).

"-c, --configfiles" Вывести список только конфигурационных файлов (подразумевает -l).

"--scripts" Вывести специфические для данного пакета скрипты, используемые как часть процессов инсталляции/деинсталляции, если таковые есть.

"--triggers, --triggerscripts" Показать все триггер-скрипты, если таковые имеются, содержащиеся в пакете.

"--dump" Вывести информацию о файлах следующим образом: path size mtime md5sum mode owner group isconfig isdoc rdev symlink.
Эта опция должна использоваться в сочетании с по меньшей мере одной из -l, -c, -d.

"--last" Упорядочивает список пакетов по времени установки таким образом, что наиболее свежие пакеты находятся в верху списка.

"--filesbypkg" Показывает все файлы в каждом пакете.

"--triggerscripts" Показывает все триггер-скрипты для выбранных пакетов.

ОПЦИИ ВЕРИФИКАЦИИ.

Общая форма команды верификации rpm выглядит так:
rpm -V|-y|--verify [опции-верификации]
В процессе верификации пакета информация об инсталлированых файлах пакета сравнивается с информацией из оригинального пакета и из базы данных RPM. В числе прочих, верификация проверяет размер, контрольную сумму MD5, права доступа, тип, хозяина и группу каждого файла. Все несоответствия докладываются. Опции выбора пакетов такие же, как и для запроса(инспекции) пакетов.

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

Опции, которые могут быть использованы в процессе верификации:

"--nofiles" Игнорировать отсутствующие файлы.

"--nomd5" Игнорировать ошибки контрольной суммы MD5.
"--nopgp" Игнорировать ошибки подписи PGP.

Форматом вывода является строка из восьми символов, возможное "c", указывающее на конфигурационный файл, и имя файла. Каждый из восьми символов показывает результат сравнения одного из атрибутов файла со значением, записанным в базе данных RPM. Точка обозначает, что тест проlел. Следующие символы говорят об ошибках некоторых тестов:

"5" Контрольная сумма MD5.

"S" Размер файла.

"L" Симлинк.

"T" Время модификации.

"D" Устройство.

"U" Хозяин.

"G" Группа.

"M" Права доступа (включает права доступа и тип файла).

ПРОВЕРКА ПОДПИСИ

Общая форма команды проверки подписи RPM выглядит так:
rpm --checksig <файл_с_пакетом>+
Эта команда проверяет PGP-подпись, встроенную в пакет, для подтверждения целостности и источника происхождения пакета.
Информация о конфигурации PGP читается из конфигурационных файлов. Более детально см. секцию ПОДПИСИ PGP.

ОПЦИИ УДАЛЕНИЯ (ДЕИНСТАЛЛЯЦИИ)

Общая форма команды удаления (деинсталляции) rpm выглядит так:
rpm -e <название_пакета>+

"--allmatches" Удалить все версии пакета, отвечающие <название_пакета> Обычно, если <название_пакета> отвечает нескольким пакетам, выдается
сообщение об оlибке и удаление не производится.

"--noscripts" Не исполнять пре- и постустановочные скрипты.

"--notriggers" Не исполнять триггер-скриптов, взведенных на удаление данного пакета.

"--nodeps" Не проверять зависимостей перед удалением пакетов.

"--test" Не производить удаления, только сделать вид что:) Полезна в сочетании с опцией -vv.

Разное:
rpm [--showrc]
rpm [--setperms] [пакет]+
rpm [--setgids] [пакет]+

ОПЦИИ FTP/HTTP.

rpm содержит простые клиенты FTP и HTTP для упрощения установки и изучения пакетов, доступных через Интернет. Файлы пакетов для установки,
обновления и запроса могут быть указаны как ftp или http style URL:
ftp://:@hostname:/path/to/package.rpm
Если часть Опущена, пароль будет запроlен (по одному разу для каждой пары user/hostname). Если ни , ни Не указаны, будет использован anonymous ftp. Во всех случаях используется пассивная (PASV) пересылка по FTP.

Rpm позволяет использовать с ftp URL следующие опции:

"--ftpproxy " Система будет использована как прокси-сервер для всех пересылок, что позволяет производить FTP-соединения через firewall, использующий прокси для выхода во внеlний мир. Эта опция может быть задана также настройкой макроса _ftpproxy.

"--ftpport " Задает номер TCP-порта, используемого для FTP-соединений вместо порта по умолчанию.
Эта опция может быть также задана настройкой макроса _ftpport.

Rpm позволяет использовать с http URL следующие опции:

"--httpproxy " Система будет использована как прокси-сервер для всех пересылок, что позволяет производить HTTP-соединения через firewall, использующий прокси для выхода во внеlний мир. Эта опция может быть задана также настройкой макроса _httpproxy.

"--httpport " Задает номер TCP-порта, используемого для HTTP-соединений вместо порта по умолчанию.
Эта опция может быть также задана настройкой макроса _httpport.

Подготовил Dvoe4nik85

RPM (RedHat Package Manager) - самая популярная утилита управления пакетами для систем на базе RedHat , таких как RHEL , CentOS , Fedora . Инструмент позволяет системным администраторам и пользователям устанавливать, обновлять, удалять, запрашивать, проверять и управлять пакетами системного программного обеспечения в операционных системах Unix/Linux . Менеджер пакетов RPM хранит информацию об установленных в системе приложениях в свой базе данных /var/lib/rpm . Сами.rpm файлы содержат скомпилированные версии программного обеспечения, библиотеки необходимые для их работы, а так-же актуальную информацию об источниках пакетов, версиях и зависимостях. RPM не может управлять программным обеспечением скомпилированным и установленным из исходных кодов.

По сути RPM работает в нескольких режимах. Запросы и проверки:

• rpm {-q|--query}
• rpm {-V|--verify}

• rpm {-i|--install} PACKAGE_FILE ...
• rpm {-U|--upgrade} PACKAGE_FILE ...
• rpm {-F|--freshen} PACKAGE_FILE ...
• rpm {-e|--erase} [--allmatches] [--justdb] [--nodeps] [--noscripts][--notriggers] [--test] PACKAGE_NAME ...

1. Проверить gpg подпись rpm пакета

2. Установка rpm пакета

3. Проверить зависимости rpm пакета перед установкой

4. Rpm, установка пакетов без зависимостей

5. Rpm, проверить установленный пакет

6. Rpm, список файлов установленного пакета

7. Rpm, список последних установленных пакетов

8. Rpm, вывести список всех установленных пакетов

9. Обновление rpm пакета

10. Удаление rpm пакета

11. Удаление rpm пакета без зависимостей

12. Rpm, запросить файл принадлежащий пакету

13. Rpm, получить информацию об установленном пакете

14. Rpm, получить информацию о пакета который еще не установлен

15. Rpm, посмотреть файлы документации определенного пакета

16. Проверка определенного rpm пакета

17. Проверка всех rpm пакетов

18. Импорт GPG ключа

19. Rpm, посмотреть все импортированные ключи

20. Перестроить поврежденную базу данных rpm

Материал из Rosalab Wiki

Этот документ нацелен на то, чтобы помочь людям, которые хотят выпускать пакеты для дистрибутива ROSA Desktop. В частности, он подчёркивает, чем пакеты ROSA отличаются от пакетов, написанных для других дистрибутивов, основанных на RPM. Этот документ может быть полезен разработчикам ROSA, а также сторонним разработчикам.

ROSA Desktop - дистрибутив операционной системы GNU/Linux - выпускается и издаётся компанией РОСА, силами различных добровольцев, тестеров, переводчиков.

Предисловие

Предполагается, что читатель имеет опыт использования Linux. Ему должны быть известны основные команды, структура каталогов, и ему уже приходилось использовать rpm хотя бы для установки пакетов.

Этот документ построен таким образом, чтобы провести читателя шаг за шагом к получению rpm-пакета, который смог бы хорошо интегрироваться в ROSA Desktop.

В первом приближении, RPM обозначает три понятия:

• программу, предназначенную для установки или создания пакетов;
• формат, использующийся в пакетах (двоичных или исходного кода), созданных программой rpm ;
• файл, который называется «пакетом», содержащий бинарный или исходный код, и информационный заголовок. Заголовок содержит инструкции по установке и удалению программы.

Программа rpm , с пользовательской точки зрения - мощный менеджер пакетов. Она играет роль посредника для любых действий, выполняемых с пакетами rpm. Кроме того, она может:

• установить или обновить пакет, учитывая зависимости;
• во время установки пакета подготовить действия, чтобы сделать установленную программу готовой к использованию;
• восстановить случайно удалённые файлы, принадлежащие пакету;
• показать информацию о том, что данный пакет уже установлен;
• найти пакет, к которому относится определённый файл;
• проверить текущую установку на выполнение требования зависимостей уже установленных пакетов;

С точки зрения программиста, программа rpm - упаковщик, скрывающий в одном единственном rpm-файле всю информацию, необходимую для установки программы на данную платформу.

Важно различать с самого начала пакеты с исходным кодом .src.rpm , и бинарные пакеты (пакеты, содержащие двоичный код) ..rpm .

Установка программного обеспечения

Основы

Хотя изначально программа rpm была разработана для дистрибутива Red Hat Linux , она также работает и в других дистрибутивах, основанных на rpm: OpenMandriva , Suse , Fedora и т. д.; на всех этих системах программа rpm уже установлена.

Бинарный rpm-пакет, который вы будете собирать для ROSA, может не работать в других дистрибутивах.

Сборка пакетов для ROSA Desktop

Сборка пакетов для Cooker (т. е. разрабатываемой версии ROSA Desktop) всегда сопровождается применением патчей и прочих улучшений со стороны rpm . Перед началом сборки убедитесь, что в системе установлены все перечисленные ниже пакеты:

$ sudo urpmi rpm rpm-build spec-helper libtool rpmlint

• rpm - сам rpm;
• rpm-build - содержит сценарии, используемые при сборке пакетов;
• spec-helper - инструмент для минимализации спек-файлов с помощью некоторой автоматизации: разбор бинарных файлов, сжатие страниц руководств (man-страниц);
• libtool - используется некоторыми конфигурационными сценариями для сборки совместно используемых библиотек;
• rpmlint - используется для проверки корректности сгенерированного файла src.rpm .

Предварительные задачи

Создание требуемых папок

Перед тем, как приступить к сборке, нужно позаботиться об организации «рабочего места»: программе rpm необходимо определённое дерево каталогов в вашем «домашнем» каталоге. Это дерево можно создать с помощью следующей команды: mkdir -p ~/rpm/{BUILD,RPMS/$ARCH,RPMS/noarch,SOURCES,SRPMS,SPECS,tmp} .

Замените $ARCH на название архитектуры, для который планируется выполнять сборку. Обычно это i586 или x86_64 , но может быть также sparc , alpha или ppc .

Примечание
Сборка rpm -пакетов с правами суперпользователя может быть опасной, потому что бинарные файлы устанавливаются в систему перед пакетированием, таким образом, всегда нужно собирать пакеты с правами нормального пользователя, если вы не хотите случайно засорить систему.

Дерево каталогов должно иметь следующую структуру:

• ~/rpm/BUILD : каталог для собранных исходников.
• ~/rpm/RPMS : содержит каталоги, по одному каталогу на каждую архитектуру, куда кладутся бинарные пакеты после сборки.
• ~/rpm/RPMS/i586 : каталог для хранения rpm-пакетов для процессоров i586 .
• ~/rpm/RPMS/x86_64 : каталог для хранения rpm-пакетов для процессоров x86_64 .
• ~/rpm/RPMS/noarch : каталог для хранения rpm-пакетов, не зависящих от архитектуры процессора.
• ~/rpm/SOURCES : файлы исходного кода (например, mypackage.tar.bz2 ).
• ~/rpm/SPECS : спек-файлы, которые мы должны построить.
• ~/rpm/SRPMS : собранные src.rpm -пакеты.
• ~/rpm/tmp : для временных файлов, которые создаются программой rpm во время сборки пакетов.

Примечание
программе rpm необходимы каталоги для различных архитектур в ~/rpm/RPMS . Если они отсутствуют, вы получите сообщение об ошибке.

Не создавайте файл .rpmmacros

Ряд руководств по сборке пакетов RPM советуют создать в «домашнем» каталоге файл конфигурации .rpmmacros с персональной информацией, которая будет добавлена в метаданные пакета, такой как значения %packager, %vendor и другие. Не делайте этого. Все подобные поля заполняются автоматически системой сборки. Однако, Вы все-таки можете создать этот файл, если Вы хотите указать другую директорию для сборки, отличную от /home/user/rpm. В этом случае укажите значения только для %_topdir и %_tmppath макросам. Не указывайте значения для других макросов.

Сборка RPM

Из существующих «исходников» RPM

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

Последнюю версию rpm-файла можно взять из Cooker. Список зеркал Cooker находится на странице зеркала Cooker . Там можно найти:

* "media/jpackage для бинарных rpm noarch. (jpackage нет)

Чтобы изменить source rpm для ROSA Linux, введите команду rpm -ivh мой_пакет.src.rpm . Эта команда установит все файлы с исходными кодами в созданный вами каталог ~/rpm .

Примечание
Программу urpmi можно настроить таким образом, чтобы она сама загружала «исходники».

Например:

$ rpm -i /cooker/SRPMS/ktron-1.0.1-2mdv.src.rpm $ ls -R * SRPMS: SPECS: ktron.spec SOURCES: ktron-1.0.1.tar.bz2 RPMS: noarch/ i686/ i586/ i386/ BUILD:

Из приведённого выше примера видно, что программа rpm установила в rpm-дерево файл с исходными кодами ktron-1.0.1.tar.bz2 и спек-файл. Было бы полезным пересобрать текущую версию пакета, чтобы понять, как он компилируется. Для этого нужно воспользоваться программой rpmbuild , запустив её с опцией buildall :

$ cd ~/rpm/SPECS $ rpmbuild -ba ktron.spec $ ls -l ~/rpm/RPMS/i586/ktron-1.0.1-2mdv.i586.rpm $ ls -l ~/rpm/SRPMS/ktron-1.0.1-2mdv.src.rpm

Если сборка завершилась без ошибок (а она, кстати, может длиться несколько часов, если собирается какой-нибудь сложный пакет, например, ядро), собранный пакет и пакет с исходными кодами будут находиться в каталогах ~/rpm/RPMS/i586 и ~/rpm/SRPMS/ соответственно. Для того, чтобы установить собранный пакет, необходимо получить права суперпользователя. Для этого нужно ввести в терминале команду su и ввести пароль суперпользователя. Чтобы выйти из режима суперпользователя используйте клавиатурное сочетание клавиш «Ctrl+D» или наберите команду exit . Для сборки и пересборки пакетов с «исходниками» привилегий суперпользователя не требуется.

Журнал сборки может быть достаточно объёмным, его можно сохранить для последующего просмотра.

В подкаталогах ~/rpm/BUILD обычно можно получить доступ к пропатченным «исходникам» (если один или более патчей находились в каталоге ~/rpm/SOURCES ), бинарникам, скомпилированным библиотекам, страницам руководств и т. д. Спек-файл описывает исходный код и патч-файлы, способы сборки и установки пакета.

Теперь, чтобы исправить ktron , нужно лишь внести изменения в спек-файл, а затем пересобрать пакет.

Примечание
Каждый пакет, собираемый ROSA Desktop, использует систему контроля версий CVS. Это позволяет записывать каждое состояние пакета, т. е. разработчик может обратиться к архиву для просмотра сделанных изменений. Если сделанные изменения по каким-либо причинам не являются желательными, разработчик может их отменить.

Каждый спек-файл хранится в модуле SPECS/ или contrib-SPECS/ . К нему можно получить доступ на cvs.mandriva.com .

Сборка из исходных текстов

Допустим, вы нашли интересную программу на сайте Freshmeat или , и вы хотите, чтобы эта программа стала доступной для всех пользователей ROSA Desktop.

Скачайте архив с исходным кодом и поместите его в каталог SOURCES .

Предварительные проверки

Примечание
Для критических к безопасности пакетов мы рекомендуем не изменять исходный код, т. к. это приведёт к изменению контрольной суммы и подписи. Мы рекомендуем оставлять такие пакеты в их исходном состоянии, примером такого пакета может служить OpenSSH.

Внутри spec-файла

Вот мы и добрались до одной из важнейших глав этого документа. Spec-файл содержит всю необходимую информацию для:

• компиляции программы, сборки исходного кода и бинарного rpm-пакета;
• установки и удаления программы.

Короче говоря, спек-файл описывает моделируемую компиляцию и установку, говорит rpm , какие файлы, полученные в результате инсталляции, должны быть упакованы, и как они должны в итоге устанавливаться в системе. Команды выполняются с использованием командной оболочки /bin/sh , таким образом, конструкции команд вида [ -f configure.in ] && autoconf являются корректными и их можно применять.

Мы рассмотрим основные возможности, используемые в одном из спек-файлов. По мере того, как вы будете собирать всё больше и больше rpm-пакетов, вы поймёте, что существуют некоторые дополнительные параметры, о которых мы не рассказывали. Более подробную информацию можно получить в книге Maximum RPM (см. раздел 7).

Рассмотрим следующий пример спек-файла, взятого из Cooker:

Name: gif2png Summary: Tools for converting websites from using GIFs to using PNGs Version: 2.0.1 Release: 1 Source0: http://www.tuxedo.org/~esr/gif2png/%{name}-%{version}.tar.bz2 Source1: %{name}-%{version}-rosa-addon.tar.bz2 Patch0: gif2png-2.0.1-bugfix.patch URL: http://www.tuxedo.org/~esr/gif2png/ Group: Applications/Multimedia License: MIT-like Requires: python %description Tools for converting GIFs to PNGs. The program gif2png converts GIF files to PNG files. The Python script web2png converts an entire web tree, also patching HTML pages to keep IMG SRC references correct. %prep %setup -q -a 1 %patch -p1 %build %configure %make %install %makeinstall %files %defattr(0755,root,root) %doc README NEWS COPYING AUTHORS %{_mandir}/man1/gif2png.1* %{_mandir}/man1/web2png.1* %{_bindir}/gif2png %{_bindir}/web2png # При подготовке пакетов для ROSA не создавайте раздел %changelog самостоятельно! %changelog * Mon Nov 02 1999 Camille Begnis 2.0.1-rosa2012 - Upgraded to 2.0.1 * Mon Oct 25 1999 Camille Begnis 2.0.0-rosa2012 - Specfile adaptations for Mandrake - add python requirement - gz to bz2 compression

Символ «%» в начале строки может означать:

• начало секции (раздела) (prep , build , install , clean );
• встроенный макрос сценария командной оболочки (setup , patch );
• директива, используемая специальными секциями (разделами) (defattr , doc , ...).

Раздел заголовка (header )

Эти три строки автоматически определяют константы, которые можно использовать в других разделах спек-файла, называемые %{name} , %{version} и %{release} . Некоторые пакеты могут формировать релиз с помощью устаревшего макроса %mkrel , который в дистрибутивах ROSA просто возвращает свой аргумент.

Кроме того, есть несколько тегов, о которых вы, возможно, захотели бы узнать, но которых нет в примере спек-файла. Есть некоторые теги, которые вы можете встретить. Никто не требует, чтобы вы помнили все теги, если вы только приступили к сборке rpm-пакетов, но после некоторого времени этот список может послужить хорошей отправной точкой!

Теперь настало время объяснить, как формируется имя пакета. Очень важно всегда следовать этому соглашению, чтобы ваша работа была понятной для остальных.

• Бинарный пакет обозначается следующим образом: имя-версия-релиз.arch.rpm (name -version -release .arch.rpm)
• Пакет с исходным кодом обозначается следующим образом: имя-версия-релиз.src.rpm (name -version -release .src.rpm) (т. е. в нашем случае - gif2png-2.0.1-1mdk.src.rpm )

Имя, в основном, выбирается, исходя из названия главного бинарного пакета, хотя, при наличии веских причин, можно использовать другое имя.

Версия - это номер в имени оригинального исходного файла архива: name-version.tar.gz .

Релиз - это число, следующее за версией, увеличиваемое с каждой новой сборкой пакета, которая может быть связана с применением дополнительных патчей, изменениями внесёнными в спек-файл и даже тривиальным обновлением пиктограммы.

Summary: tools for converting websites from using GIFs to using PNGs

Эта строка представляет собой описание пакета.

Source0: http://www.tuxedo.org/~esr/gif2png/%{name}-%{version}.tar.bz2

Эта строка говорит rpm , какой файл исходного кода должен быть использован для сборки пакета. Заметьте, что имени файла предшествует полный URL (что, в общем случае, не обязательно), указывающий на веб-сайт, на котором расположен оригинальный исходный код. rpm уберёт URL, сохранив только имя файла, и произведёт поиск в каталоге SOURCES . Хотя предоставление полного URL и не является обязательным, его использование строго рекомендуется, таким образом любой желающий сможет узнать, где можно скачать исходники.

Если файлов с исходным кодом несколько, используйте несколько строк, начинающихся с Source1: … , Source2: … и т. д. соответственно.

Patch0: gif2png-2.0.1-bugfix.patch

Это необязательный тег. Его можно использовать в двух случаях:

1. Вы исправили ошибку в исходном коде программы и создали патч , который должен быть применён к исходному коду программы перед компиляцией.
2. Вы узнали, что для данного пакета программы где-то в сети есть патч, и скачали этот патч.

Все патчи должны находиться в каталоге SOURCES . Если патчей несколько, то они должны называться Patch1 , Patch2 и т. д.

URL: http://www.tuxedo.org/~esr/gif2png/

Эта строка указывает на домашнюю страницу программы. Её использование не является обязательным, но мы всё же рекомендуем её указывать.

Group: Multimedia

Этот фрагмент говорит программе rpm , в какой части дерева пакетов разместить наш пакет. Эта возможность используется фронт-эндами пакетных менеджеров таких, как rpmdrake и kpackage .

Полная структура групп, которая, кстати говоря, отличается от аналогичных групп Red Hat, представлена на странице Packaging group . Очень важно следовать принятым соглашениям о группах, иначе ваш пакет внесёт неразбериху в дерево пакетов.

License: MIT-like

Этот тег определяет лицензию, выбранную держателем авторских прав, которая будет применяться к программному обеспечению, находящемуся в пакете. Чаще всего это GPL. На страницах лицензии РОСА и политика лицензирования представлены полные списки разрешённых к использованию лицензий.

BuildRequires: python

Обозначает, что для компиляции rpm потребуются библиотеки языка python, часто необходимо указывать, например, libpyglib-gi2, python-devel, если какой-то пакет не найти сразу, то можно поискать его с помощью команды urpmi -p ИмяПакета, так как он может содержаться в другом пакете, это указывается командой

Provides: libgif2png

в Provides указывается имя библиотеки, которая может использоваться другими программами (предоставляется)

Requires: python

Эта строка была добавлена, потому что одна из программ, включённых в пакет, является сценарием написанным на языке программирования Python. Это означает, что для корректной работы программы потребуется интерпретатор python .

Можно использовать требование к минимальной (или конкретной) версии. Например:

Requires: python >= 1.5.1

В редких случаях приложение может конфликтовать с другими уже установленными библиотеками или старыми версиями приложений, чтобы убрать их из системы при установке нужно сообщить об этом пользователю, для этого используется тег

Conflicts: python <= 1.0.0

Некоторые пакеты становятся устаревшими после установки новых библиотек, чтобы отметить их и удалить используется тег

Obsoletes: gif2png < 2.0.0

Ниже следует тег описания:

%description Tools for converting GIFs to PNGs. The program gif2png converts GIF files to PNG files. The Python script web2png converts an entire web tree, also patching HTML pages to keep IMG SRC references correct.

Это совершенно особый тег внутри заголовочной части спек-файла, потому что он содержит текст, который может занимать произвольное количество строк и параграфов. Текст содержит полное описание программного обеспечения, которое помогает пользователю решить нужно ли устанавливать данный пакет или нет. В целях улучшения восприятия спек-файлов, переводы тегов summary и description хранятся в специальных файлах, называемых Po .

%defattr(0755,root,root)

Этот тег задаёт атрибуты, которые будут применяться ко всем файлам, копируемым в систему пользователя. Аргументы означают:

• -: все атрибуты для регулярных файлов остаются неизменными;
• root: владелец файла - root;
• root: группа файла - root;
• 0755: атрибуты, применённые ко всем каталогам, принадлежащим пакету - 0755 (rwxr-xr-x ).

Специальный тег %doc помечает файлы, которые являются частью документации пакета. Файлы документации будут помещены в /usr/share/doc/gif2png-2.0.1/ . Этот каталог будет создан автоматически. Файлы %doc задаются относительно каталога извлечённых из tar-архива исходников в каталоге BUILD .

%{_mandir}/man1/gif2png.1* %{_mandir}/man1/web2png.1*

Также, вы можете задаться вопросом: почему вместо gif2png.1.lzma используется gif2png.1* ? Это сделано для того, чтобы сохранить совместимость с другими системами, которые используют сжатие gzip вместо lzma. Если вы нашли такие ссылки на lzma сжатие в спеке, замените их регулярным выражением, как в примере выше. Чаще всего вы можете использовать %{_mandir}/man1/* , что соответствует всем файлам в директории man1.

%{_bindir}/gif2png %{_bindir}/web2png

Как вы можете видеть, для каждого необходимого пути есть макрос нужного типа. Вот наиболее полезные: (полный список доступен в файле /usr/lib/rpm/macros ): %{_prefix} , %{_bindir} , %{_sbindir} , %{_datadir} , %{_libdir} , %{_sysconfdir} , %{_mandir} , %{_infodir} . Для игр используйте %{_gamesbindir} и %{_gamesdatadir} .

Раздел журнала изменений (changelog )

Внимание! Здесь представлена общая информация о секции changelog . Вы не должны добавлять эту секцию в spec-файл самостоятельно, поскольку она генерируется автоматически из истории изменений в системе контроля версий.

Что такое журналы изменений

Этот раздел предназначен для хранения записей о различных изменениях, сделанных в пакете. Каждая новая сборка пакета должна сопровождаться параграфом в этом разделе, также как и каждый новый номер версии программы. Соблюдается следующая структура этих параграфов:

* Mon Nov 02 1999 Camille Begnis 2.0.1-1mdk

• первая строка параграфа начинается со знака звёздочки «*» и отделяется от неё пробелом;
• три буквы, обозначающие день недели;
• три буквы, обозначающие месяц;
• две цифры дня месяца;
• четыре цифры года;
• имя человека, создавшего пакет;
• его же фамилия;
• его же адрес электронной почты в угловых скобках «<>»;
• текущая версия и релиз.

Затем следует одна строка, начинающаяся с «-», в которой описывается изменение в пакете.

Spec file stolen from korganizer. - last snapshot before release - ROSA adaptations. - Fix bug in /etc/zsh use USERNAME instead of USER. - Remove petit bouchon which annoys other players. - Improve /etc/z* to source the /etc/profile.d/ files. - fix typo in examples directory name - fixed QT libs version requirements - add patch to handle Earl Grey tea

По умолчанию в собранный пакет помещаются только записи не старше 1 года. Это поведение может быть изменено настройкой значения %_changelog_truncate

История изменений в системе контроля версий

Информация для секции changelog автоматически генерируется из истории изменений системы контроля версий. Каждая строка сообщения из истории изменений становится записью в секции changelog , начинающейся с дефиса. Сообщения автоматически группируются по имени и email-адресу автора.

Если вы не хотите, чтобы строка из истории изменений попала в changelog пакета, добавьте в начале строки "SILENT: ". Пустые строки также игнорируются.

Сборка

Наконец, наш спек-файл готов. Наберите грудью побольше воздуха, присядьте и наберите команду rpmbuild -ba mypackage.spec .

Также можно добавить параметр --clean , который очистит каталог BUILD после завершения сборки пакета. Это может оказаться полезным, если у вас мало свободного места на жёстком диске.

Процесс может закончиться со следующими результатами:

• exit 0;
• все остальные случаи.

There are then two possibilities for the last line of your process:

• 0.01% probabilities: + exit 0
• 99.99% probabilities for other cases.

You are in the second case? Congratulations you passed the test, you are not an alien.

Good luck, so long, have a look to rpm building options (man rpmbuild ) to debug your work, look at other persons" specfiles, etc..

There is a very clean way to build packages: use rpmbuild -bs --rmspec --rmsource (in order to remove anything from the original build) and then do a rpmbuild --rebuild .

Оптимизация процесса сборки

Когда вы запускаете команду для сборки вашего пакета, вы точно были уведмлены сообщением вида: foo-devel is necessary for foo2 .

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

Сборочный кластер ROSA имеет множество таких предустановленных пакетов для разработки (devel -пакетов). В случае, если один из обязательных пакетов не был перечислен в спек-файле, пакет будет собран на кластере в любом случае. Но отсутствие такой информации не позволит собрать пакет на машинах, на которых отсутствует devel-пакет, делая отладку и обновление более трудной.

Взгляните на веб-сайт программы, для которой подготавливается пакет, там можно найти информацию о необходимых компонентах.

Чтобы найти эти "missing BuildRequires", выполняя сборку, в системе должны присутствовать только самые основные пакеты для разработки:

• glibc-devel
• libncurses5-devel
• libstdc++6-devel

После этого устанавливайте только те пакеты для разработчиков, которые попросит команда сборки rpm .

Запуская сборку, следите за сообщениями checking for...

Если вы увидите что-то наподобие checking for foo... foo.h not found , это означает, что заголовочный файл в вашей системе не найден. Найдите пакет для разработк, содержащий foo.h , но будьте осторожны: вы можете найти больше одного пакета. Поэтому выберите тот, что подходит в наибольшей степени. К примеру, не следует выбирать пакет, имеющий отношение к компьютерной сети, если вы собираете приложение, предназначенное для работы со звуком.

Затем, установите пакет в систему, не забудьте добавить его имя в раздел BuildRequires вашего спек-файла.

Отсутствующие заголовочные файлы могут быть найдены во время компиляции. Если она останавливается, проверьте наличие других foo.h и примените тот же способ.

Проверка RPM-пакета

Основные проверки

Перво-наперво нужно проверить следующее:

• созданы ли rpm в соответствующих каталогах с корректными именами (в каталогах ~/rpm/SRPMS/ и ~/rpm/RPMS/i586/ );
• корректна ли информация, полученная с помощью команды rpm -qlivp --changelog мой_пакет.(src.)rpm .

Запуск Rpmlint

После этого, вы должны воспользоваться утилитой Rpmlint , которая выполнит различные проверки пакета. Перед запуском rpmlint убедитесь, что у вас установлен пакет rpmlint-mandriva-policy , содержащий правила проверки для Росы. Наберите rpmlint мой_пакет..rpm для получения отчёта об определённом пакете. Чтобы получить более подробную информацию, используйте ключ -i . Вы должны проверить rpm и src.rpm . Дополнительную информацию по ошибкам, которые встречаются при сборке, можно найти на странице проблемы сборки пакетов .

Install test

Теперь необходимо проверить установку и обновление пакета на любой машине (желательно отличной от той, на которой проходила сборка), и удостовериться, что:

• Созданы все необходимые файлы с нужными правами и владельцами
• Все скрипты, выполняющиейся при установке, отработали успешно
• У всех исполняемых файлов установлен бит executable , а файлы с документацией доступны всем пользователям

Для полноты тестирования можно также проверить процесс удаления пакета, функциональность установленного ПО и тому подобное.

Если все тесты прошли успешно, то вы почти у цели - осталось только отправить пакет в репозиторий.

Что-то пошло не так?

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

1. Официальный документ RPM-HOWTO (устанавливается в систему вместе с программой rpm ).
2. Книга Red Hat Maximum RPM , которая доступна на http://www.redhat.com/docs/books/max-rpm/max-rpm-html/ .
3. посмотрите на spec-файлы схожих пакетов - возможно, их авторы сталкивались со схожими проблемами
4. Задайте вопрос в почтовой рассылкеразработчиков ROSA .

Если вы полагаете, что найденные вами решения могут быть полезны остальным, сообщите об этом авторам документов, в которые вы бы хотели добавить описания этих решений.

Предустановочные и постустановочные сценарии

Основы

RPM-пакет представляет из себя нечто большее, чем просто архив с файлами, которые извлекаются в определённые каталоги на клиентских системах.

Система предоставляет программистам мощную возможность: предустановочные и постустановочные сценарии. Эти сценарии позволяют сборщику пакета вписать фрагмент кода, который будет запущен на клиентской машине при установке или удалении пакета.

Эти сценарии создаются из любых допустимых команд интерпретатора командной строки. Вот четыре из них:

Имеются некоторые предупреждения относительно этих сценариев. Во-первых, вы должны уложиться в размер буфера 8192, во-вторых, сценарии не должны быть интерактивными. Всё, что требует от пользователя ручного ввода, является неверным, т. к. это нарушает неинтерактивность процедур установки RPM.

• %pre - этот сценарий выполняется перед установкой пакета в систему.
• %post - этот сценарий выполняется после установки пакета в систему.
• %preun - этот сценарий выполняется перед удалением пакета из системы.
• %postun - этот сценарий выполняется после удаления пакета из системы.

Назначение таких сценариев может быть чрезвычайно многообразным. Сценарии должны быть спроектированы таким образом, чтобы не навредить системе. Помните, что сценарии выполняются от имени суперпользователя. Они относятся к задачам системного администрирования, завершающим установку нового приложения. Например:

• Добавить в cron запуск программы через равные интервалы времени
• Запустить chkconfig , чтобы запустить службу во время загрузки

Работа с обновлениями

Работа с пакетами осложняется тем фактом, что пакет может быть обновлен, а не просто установлен или удален. проблема заключается в том, что при обновлении скрипт %postun новой версии пакета запускается после скрипта %post старой версии, и то, что сделал последний скрипт, может быть потеряно.

Часто полезно убедиться, что те или иные действия производятся только при установке/удалении пакета, но не при обновлении. Для обработки таких ситуаций RPM передает специальный аргумент скриптам %pre , %preun , %post и %postun .

Аргумент содержит количество различных версий данного пакета, которые будут установлены на машине после выполнения данного скрипта. Например, при установке нового пакета, скриптам %pre и %post будет передано значение "1". При обновлении пакета, скрипты %pre и %post новой версии получат значение "2", скрипты %preun и %postun старой версии - "1".

Наличие такого параметра позволяет программистам различать, в какой ситуации запускается скрипт - при установке или при обновлении пакета.

• Для скриптов установки (%post , %pre ) - если параметр $1 равен "1", то происходит первоначальная установка
• Для скриптов удаления (%postun , %preun ) - если параметр $1 равен "0", то происходит удаление пакета; иначе это обновление либо установка с опцией --force.

Для проверки значение параметра, можно использовать следующую конструкцию:

%postun if [ $1 -eq 0 ]; then ### Выполнение действий, специфичных для удаления пакета fi if [ $1 -eq 1 ]; then ### Выполнение действий, специфичных для обновления пакета fi

Файловые триггеры

Чтобы избавиться от необходимости выполнения часто встречающихся задач - таких как выполнение "%post -p /sbin/ldconfig" или "%update_menus" - в ROSA используются файловые триггеры RPM .

More macros

При сборке пакетов для Росы, вы можете использовать в spec-файле различные макросы для выполнения типичных задач.

• Обработка info-старниц:

• Обновление системы меню. В Росе используется Меню XDG .

• Обработка файлов локализации. Хорошей практикой является не ручное перечисление всех .mo -файлов, которые обычно находятся в поддиректориях /usr/share/locale/.. , а использование специального макроса в секции %install , которые создаст отдельный файл с перечнем файлов с локализациями:

Созданный файл необходимо указать в секции files :

%files -f %{name}.lang

• Макропопределения, используемые при сборке - %configure и %makeinstall . Они автоматически устанавливают префикс для установки, а также различные директории (такие как bindir, datadir и другие). Как правило, эти макросыф отлично работают с небольшими пакетами, но могут потербовать дополнительной настройке при сборке сложных продуктов. Макрос %make вызывает команду make с соответствующей опцией -j , распараллеливая сборку на многоядерных машинах. Если вам все-таки необходимо вызвать скрипт ./configure напрямую, никогда не указывайте название целевой аппаратной архитектуры. Для этих целей есть макрос %{target platform} (или даже %{target cpu} , если необходима более точная информация).
• Сборка серверного ПО. Для сборки, от которого требуется повышенная надежность в ущерб производительности, мы используем специальный макрос %serverbuild , который необходимо вызвать до начала самой сборки. Этот макрос выставляет необходимые значения флагов оптимизации. Секция %build при этом выгдядит следующим образом:

• Макросы для init-скриптов. При установке пакета, в котором содержится init-скрипт (файл в директории /etc/init.d ), необходимо зарегистрировать этот скрипт вызовом chkconfig --add .. ; при обновлении, этого делать не надо, но если скрипт работает, то он должен быть перезапущен; при удалении пакета, необходимо удалить информацию о скрипте. Для этих целей у нас есть соответсвующий макрос: