Материал из 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 . Там можно найти:

SRPMS Каталог для хранения rpm с «исходниками» (main , contrib , non-free , др.) для различных процессорных архитектур (i586 , x86_64 , …); media/main Для бинарных rpm из main ; media/contrib Для бинарных rpm из contrib ; media/non-free Для бинарных rpm из non-free ;

* "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 .

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

Лицензия Несмотря на распространённость лицензии GPL, есть ещё множество не-GPL лицензий. Необходимо точно определить лицензию программного обеспечения, чтобы узнать, можно ли включать его в дистрибутив. Мы не принимаем программы, использующие проприетарные лицензии, но для клуба есть несколько исключений. Также, мы не можем принять программы, которые не позволяют нам свободно их распространять. Список лицензий, которые разрешены к использованию в дистрибутиве, находится на странице Mandriva . Сжатие tar-архива Мы рекомендуем использовать исходный tar-архив без каких-либо изменений. Если исходники распространяются с использованием различных методов сжатия, мы часто отдаём предпочтение .tar.bz2 . Избегайте сжатия патчей (полученные diff и др. подобными программами) и других текстовых файлов (файлы настроек, сценарии и т. д.), т. к. они занимают, как правило, очень мало места, в противном случае будет сложнее увидеть изменения в файлах различий (diff-файлах) Subversion (Subversion в свою очередь сам использует некоторую форму сжатия).

Примечание
Для критических к безопасности пакетов мы рекомендуем не изменять исходный код, т. к. это приведёт к изменению контрольной суммы и подписи. Мы рекомендуем оставлять такие пакеты в их исходном состоянии, примером такого пакета может служить 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: gif2png Version: 2.0.1 Release: 1

Эти три строки автоматически определяют константы, которые можно использовать в других разделах спек-файла, называемые %{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 README NEWS COPYING AUTHORS

Специальный тег %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-файл самостоятельно, поскольку она генерируется автоматически из истории изменений в системе контроля версий.

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

%changelog

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

* Mon Nov 02 1999 Camille Begnis 2.0.1-1mdk

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

- Upgraded to 2.0.1

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

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-старниц:

%post %__install_info %{name}.info %preun %__install_info %{name}.info

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

%post %{update_menus} %postun %{clean_menus}

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

%find_lang %{name}

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

%files -f %{name}.lang

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

%build %serverbuild %configure %make

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

%post %_post_service %preun %_preun_service

• Обработка ghost -файлов. Некоторые пакеты (в частности, многие игры), содержат файлы, которые в некоторый момент времени могут отсутствовать в системе. Такие файлы необходимо помечать как ghost и обрабатывать с помощью специальных макросов:

%install (...) mkdir -p %{buildroot}/var/lib/games touch %{buildroot}/var/lib/games/powermanga.hi %post %create_ghostfile /var/lib/games/powermanga.hi root games 664 (...) %files %attr(664, root, games) %ghost /var/lib/games/powermanga.hi

Макрос %create_ghostfile будет развернут в следующую конструкцию:

If [ ! -f /var/lib/games/powermanga.hi ]; then touch /var/lib/games/powermanga.hi chown root.games /var/lib/games/powermanga.hi chmod 664 /var/lib/games/powermanga.hi fi

• Привязка типов фалов.desktop / MIME к приложениям: система меню XDG позволяет привязывать приложения к файлам с заданным MIME-типом в файлах .desktop . При установке или удалении .desktop -файла, необходимо запустить утилиту update-desktop-database , используя соответствующие макросы:

%post %update_desktop_database %postun %clean_desktop_database

• База данных MIME-типов Freedesktop.org: база данных, используемая для получения всех возможных типов MIME с соответствующими расширениями файлов или их "магическими" числами, должна обновляться посредством вызова следующих макросов:

%post %update_mime_database %postun %clean_mime_database

• Кэш иконок: все пакеты, содержащие иконки, устанавливаемые в /usr/share/icons/hicolor (или другие директории, предусмотренные спецификациями freedesktop, - например, /usr/share/icons/gnome или /usr/share/icons/crystalsvg ) должны обновлять кэш иконок, как показано в следующем примере (данное требование не относится к иконкам, хранящимся в /usr/share/icons , /usr/share/icons/mini или /usr/share/icons/large ):

... %file ... %{_iconsdir}/hicolor/* %{_iconsdir}/crystalsvg/* .... %post %update_icon_cache hicolor %update_icon_cache crystalsvg %postun %update_icon_cache hicolor %update_icon_cache crystalsvg

• Регистрация схем GConf: Схемы GNOME GConf должны устанавливаться и удаляться с помощью следующих макросов:

... # каждый ключ схемы соответствует файлу с именем /etc/gconf/schemas/.schemas %define schemas apps_gnome_settings_daemon_default_editordesktop_gnome_font_rendering desktop_gnome_peripherals_keyboard_xkb fontilus themus %post %post_install_gconf_schemas %{schemas} %preun %preun_uninstall_gconf_schemas %{schemas}

• Обновление бд scrollkeeper: если устанавливается файл .omf , то необходимо обновить базу данных scrollkeeper (используемую для индексирования документации в формате docbook):

... %post %update_scrollkeeper %postun %clean_scrollkeeper

Interaction with urpmi and rpmdrake

Sometimes it"s necessary to warn the user about some particular care that should be taken when upgrading or installing a specific version of a package. rpmdrake-2.1.3-11mdk and above supports this: it searches in rpms for text files named README.install.urpmi , README.update.urpmi or README.urpmi , and displays them.

README.install.urpmi is displayed only for installed packages; README.update.urpmi only for upgraded packages; README.urpmi is displayed in both cases.

Группы пакетов ROSA

Каждый пакет должен относиться к одной из групп RPM , используемых в ROSA.

Лицензии

По вопросам, относящимся к лицензиям ПО, собираемого в пакеты, обращайтесь к Licensing policy .

Alternative: checkinstall

A very easy way to build RPMs for personal use is to install the checkinstall package; compile from source as usual (./configure && make && sudo make install), but just replace the make install step by checkinstall . This automates building an RPM, and is very simple to use. The advantage is that you don"t ever have to bypass the package manager when compiling from source. (However, it"s probably A Good Idea to build RPMs "properly" as described above, if you intend to distribute them to others.)

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

Понятие

Аббревиатура RPM (Rounds per minute) на русский язык дословно переводится как "Обороты в минуту". Это единица обозначает жесткого диска, но само по себе понятие ничего не говорит обычному пользователю. RPM жесткого диска играет роль в производительности системы, и чем выше будет скорость вращения, тем быстрее будет работать вся система в целом. Чаще всего в характеристиках к жесткому диску указывается этот параметр, и между двумя твердыми носителями желательно выбирать тот, у которого RPM будет выше.

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

Что такое шпиндель?

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

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

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

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

Как это работает?

Чтобы понять точнее, что это - RPM, необходимо понять принцип работы самого устройства. При запросе определенной информации блок магнитных головок переходит к запрошенной дорожке. На это требуется определенное время для поиска (Seek latency). После того как считывающие головки перемещаются в нужный сектор, необходимо дождаться поворота дисков, чтобы нужный участок оказался под считывающей головкой. Этот участок времени называют задержкой на вращение. Именно этот параметр зависит от скорости вращения шпинделя, и чем он будет выше, тем задержка на вращение будет ниже.

Обе задержки (на перемещение шпинделя и на вращение дисков) определяют скорость доступа системы к данным. Многие программы тестирования производительности просчитывают данный параметр и выводят его под строками "Access to data time". Это позволяет определить реальную скорость работы диска. Данный параметр непосредственно влияет на производительность всей системы. Сегодня есть множество мощных ноутбуков, которые оснащаются мощными видеокартами и процессорами, большим объемом оперативной памяти. Но при этом совместно с хорошим "железом" используются очень медленные жесткие диски со скоростью вращения в 5400 оборотов в минуту. В результате все эти мощные комплектующие не работают на полную мощность из-за низкой скорости доступа к данным. Так что RPM диска важен наравне с частотой процессора и шириной шины видеокарты.

Влияние RPM HDD на производительность

Винчестеры (так часто называют жесткие диски) могут быть формата LFF и SFF. Если говорить проще, то один тип дисков имеет формат 2.5 дюйма, другой - 3.5 дюйма. Первый часто используется в ноутбуках и серверах, второй - в обычных системных блоках. Именно этот тип жесткого диска чаще всего отличается высокой скоростью вращения шпинделя - 7200 оборотов в минуту. В таких моделях время совершения полуоборота составляет 4.2 мс, а среднее время поиска равно 8.5 мс. Следовательно, время доступа к данным будет составлять 12.7 мс.

Отметим, что в большинстве стационарных компьютерах используются винчестеры SATA. 7200 RPM - это стандартная скорость для таких моделей. Бывают также диски с 5400 RPM, но их не рекомендуется использовать на современных системах, хотя стоят они дешевле. Есть также диски параметром 10000 RPM - в таких моделях задержки на поиск и вращение составляют около 3 мс. Подобные устройства чаще всего применяются на игровых компьютерах, однако даже их можно назвать устаревшими. В современных настольных ПК и ноутбуках все чаще применяют диски SSD, принцип работы которых совершенно другой. Об этом расскажем немного позже.

Нестандартный параметр RPM

Есть также на рынке модели со скоростью вращения шпинделя 15000 оборотов в минуту. Как вы догадались, там время задержек еще ниже - около 2 мс, а среднее время поиска равно 3.8 мс. Это позволяет обеспечить доступ к данным за 5.8 мс. Следовательно, диски с большим RPM имеют низкое время поиска нужной информации, за счет чего обеспечивается быстрый обмен между хранилищем информации и системой.

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

Как узнать скорость вращения шпинделя?

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

1. RPM HDD: 5400.
2. RPM: 7200.
3. RPM: 10000.

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

Популярными являются следующие:

1. Crystalmark.
2. Aida64.
3. Speccy.

Они доступны для скачивания из интернета совершенно бесплатно. Запустив одну из указанных программ, можно быстро найти информацию об устройстве хранения данных. Там будут детально отображены параметры жесткого диска. Нас в первую очередь интересует строка "Rotation Rate" и значение напротив нее. В русской версии программы Aida64 необходимо в левой части нажать на "Хранение данных" - "Хранение данных Windows", затем в верхней части нужно выделить жесткий диск, после чего снизу появится информация о нем, в том числе и строка "Скорость вращения".

Недостатки высокой скорости

Конечно, при высоком RPM обеспечивается высокая производительность системы в целом, но есть и недостатки. Чем быстрее вращается шпиндель, тем сильнее нагревается сам диск, да и работает он шумнее. Также подобные винчестеры потребляют больше электроэнергии. Впрочем, современные технологии позволяют осуществить установку RPM и уменьшить потребление энергии и шум за счет снижения скорости вращения шпинделя. Потери производительности при этом компенсируются специальным алгоритмом кэширования данных.

SSD как альтернатива

При разработке современных компьютерных платформ от использования жестких дисков с пластинами и шпинделем отказываются. Сегодня применяют твердотельные накопители, в которых отсутствуют подвижные детали вообще. "Внутренности" этих дисков представляют собой микросхемы на плате. Работают такие устройства как обычные флэшки, вот только производительность и скорость доступа к данным в них очень высокая и намного превышает производительность дисков стандарта HDD. К тому же они не шумят, являются очень легкими и потребляют мало энергии. Высокая цена - единственный недостаток. 7200 RPM на 1 Тб будет стоить дешевле, чем SSD-накопитель с емкостью 128 или 256 Гб.

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

Заключение

При выборе жесткого диска в первую очередь важно учитывать параметр производительности, который определяется скоростью вращения шпинделя в первую очередь. К сожалению, большинство пользователей смотрят на емкость дисков, хотя это не самое важное. Лучше отдать предпочтение винчестеру с емкостью 500 Гб и скоростью вращения шпинделя 7200 об/мин, чем выбирать диск на 1 Тб и с параметром RPM 5400. А вообще, сегодня нужно отходить от использования подобных систем, поскольку SSD-накопители превосходят устаревшие устройства HDD во всем.

Рано или поздно нам приходится устанавливать программное обеспечение не из официальных репозиториев. Там есть далеко не все пакеты, и не всегда есть самые новые версии, только что вышедших программ. Очень часто разработчики размещают на своем официальном сайте пакеты для самых популярных дистрибутивов. Обычно это deb и rpm. Последний встречается немного реже, но если вы используете дистрибутив на базе Red Hat, вам нужен именно этот формат пакетов. Также в сети часто можно найти библиотеки и другие компоненты, которых нет в репозиториях в виде пакетов.

Раньше мы уже рассматривали установку deb пакетов в Ubuntu. А в этой статье будет подробно разобрана установка rpm пакетов в linux.

RPM или RPM Package Manager - это пакетный менеджер, используемый в дистрибутивах Linux, основанных на Red Hat. Такое же название имеет формат файлов этого пакетного менеджера.

Этот формат не очень сильно отличается от того же самого Deb. Вы можете посмотреть их детальное сравнение в статье что . Здесь же, только отмечу, что файл rpm - это обычный cpio архив, в котором содержатся сами файлы программы, а также метаданные, описывающие куда их нужно устанавливать. База всех установленных пакетов находится в каталоге /var/lib/rpm. Из особенностей можно отметить, что rpm не поддерживает рекомендованные пакеты, а также зависимости формата или-или.

Для управления пакетами, так же как и в Debian-системах, здесь существует консольная, низкоуровневая утилита с одноименным названием - rpm. Ее мы и будем рассматривать дальше в статье. В разных системах используются разные пакетные менеджеры, например в Red Hat используется Yum, в Fedora - DNF, а в OpenSUSE - zypper, но во всех этих системах будет работать утилита rpm.

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

Давайте сначала рассмотрим синтаксис самой утилиты rpm:

$ rpm -режим опции пакет

Утилита может работать в одном из режимов:

• -q - запрос, получение информации;
• -i - установка;
• -V - проверка пакетов;
• -U - обновление;
• -e - удаление.

Рассмотрим только самые интересные опции программы, которые понадобятся нам в этой статье:

• -v - показать подробную информацию;
• -h - выводить статус-бар;
• --force - выполнять действие принудительно;
• --nodeps - не проверять зависимости;
• --replacefiles - заменять все старые файлы на новые без предупреждений;
• -i - получить информацию о пакете;
• -l - список файлов пакета;

Теперь, когда вы уже имеете представление как работать с этой утилитой, может быть рассмотрена установка rpm пакета в Linux. Самая простая команда установки будет выглядеть вот так:

sudo rpm -i имя_пакета.rpm

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

Для того чтобы посмотреть более подробную информацию в процессе установки используйте опцию -v:

sudo rpm -iv имя_пакета.rpm

Также вы можете включить отображение статус бара в процессе установки:

sudo rpm -ivh имя_пакета.rpm

Чтобы проверить установлен ли пакет, нам уже нужно использовать режим запроса:

sudo rpm -q имя_пакета

Также сразу можно удалить пакет, если он не нужен:

sudo rpm -e имя_пакета

Но у rpm так же как и у dpkg, есть один существенный недостаток. Программа не может разрешать зависимости. В случае отсутствия нужного пакета в системе, вы просто получите сообщение об ошибке и пакет не установится.

Для автоматической загрузки зависимостей во время выполнения установки rpm linux нужно использовать пакетный менеджер дистрибутива. Рассмотрим несколько команд для самых популярных RPM дистрибутивов. В RedHat и других дистрибутивах, использующих Yum используйте такую команду:

sudo yum --nogpgcheck localinstall имя_пакета.rpm

Первая опция отключает проверку GPG ключа, а вторая говорит, что мы будем выполнять установку локального пакета. В Fedora, с помощью dnf все делается еще проще:

sudo dnf install имя_пакета.rpm

Пакетный менеджер Zypper и OpenSUSE справляются не хуже:

sudo zypper install имя_пакета.rpm

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

Установка RPM файла в GUI

Если вы используете OpenSUSE, то это делается очень просто. Универсальный конфигуратор системы YaST, кроме всего прочего позволяет установить rpm пакеты. Вы можете сделать это с помощью файлового менеджера, выбрав пункт контекстного меню для файла открыть с помощью Yast или выполнив команду:

yast2 -i имя_пакета.rpm

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

Выводы

Теперь вы знаете как выполняется установка rpm файла в Linux. На самом деле это очень просто и даже существует не только один способ, а целых несколько. Хотя графических утилит здесь немного меньше чем в Ubuntu. Но консольных утилит полностью хватает. Если у вас остались вопросы, спрашивайте в комментариях!

Red Hat Package Manager (RPM) представляет собой набор инструментальных средств, служащих для создания и управления программными пакетами в Unix-системах. RPM, поставляемый вместе с Red Hat Linux и производными от него дистрибутивами, может работать с любым вариантом Unix, поскольку распространяется в исходных текстах. Однако найти RPM-пакеты для других диалектов Unix непросто.

Хотя управление пакетами строится на довольно тривиальных принципах, его реализация может оказаться делом непростым. Конечно, контролируемая установка ПО, управление уже установленными программными пакетами и их удаление из системы трудностей не представляет. RPM был создан в связи с необходимостью выполнять такие операции эффективно; другого содержательного решения тогда не было.

RPM, в отличие от ряда других менеджеров программных пакетов для Unix, использует собственный формат файлов. Это может породить серьезные проблемы, если потребуется выделить какой-то один компонент из пакета, а утилиты RPM под рукой нет. К счастью, существуют такие инструменты, как Alien, позволяющие получить файлы в формате, который допускает управление, скажем, с помощью tar или ar.

Схема именования файлов RPM сама по себе является стандартизованной конвенцией. Названия RPM имеют формат (имя)-(версия)-(сборка).(платформа).rpm. Например, название cat-2.4-7.i386.rpm используется для обозначения RPM-пакета для утилиты cat версии 2.4, сборки 7 для платформы x86. Если вместо названия платформы указано src, значит, речь идет об исходных текстах.

Зачем нужно управление пакетами?

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

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

Установка происходит без сучка и задоринки. Вы выбираете то, что вам нужно, и просите систему выполнять за вас «грязную» работу: распаковать программу, убедиться, что места хватает, разместить все в нужном порядке и установить. Отследить зависимости и дополнительные требования программного пакета для хорошего менеджера пакетов тоже не составляет труда.

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

RPM и другие

Коротко говоря, основное мое недовольство RPM связано с отсутствием для него мощного графического пользовательского интерфейса. При том, что кое-какие интерфейсы есть (такие как gnorpm и glint), в них отсутствуют более сложные функции, реализованные в SGI Software Manager. В целом, я считаю, что RPM лучше выполняет разбор и разрешение конфликтов, чем inst, и намного, намного быстрее. Так что я согласен обойтись и без мощного графического интерфейса.

В RPM меня больше всего восхищает скорость и проверка пакетов, выполняемая с помощью сигнатур пакетов и контрольных сумм компонентов. К примеру, однажды мне пришлось перезагружать SGI Software Manager только потому, что я с ошибками переустановил редактор jot. На установку этого небольшого пакета ушло около 15 минут, не считая перезагрузки.

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

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

Установка с помощью RPM

Это базовая функция RPM и одна из наиболее популярных. Для этого запустите команду

rpm -i (пакет)

В случае, если все пойдет хорошо, пакет будет установлен, и вы получите приглашение на ввод команды без каких-либо сообщений. Прискорбнее, если вам понадобится узнать, почему вас постигла неудача. Если указать флаг -h, то можно наблюдать на экране «термометр», заполняемый значками #. Судя по всему, многим нравится использовать флаги -ivh вместе:

rpm -ivh (пакет)

И опять-таки, в этом случае вы немногое узнаете о том, что происходит. Только то, что процесс установки идет без сбоев. Я же, как правило, стремлюсь при установке нового пакета получить всю возможную информацию (-vv). Это позволяет мне видеть, что происходит:

rpm -ivv (пакет)

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

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

Иногда RPM будет выдавать замечания по поводу пакетов, которые установлены, но не зарегистрированы. Возможно, вы установили их без помощи RPM (скажем, OpenSSL). Чтобы избавится от таких замечаний, вы можете заставить RPM игнорировать зависимости:

rpm -ivv -nodeps (пакет)

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

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

rpm -ivv -force (пакет)

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

Вероятно, самой большой наградой вам станет возможность использовать одну из потрясающих функций RPM: установку по сети. Иногда, в системе нет сетевых клиентов, а вам необходимо их установить через RPM. Для этого в RPM встроено программное обеспечение клиентов Web и FTP:

rpm -iv ftp://ftp.redhat.com/ path/package.rpm

rpm -iv http://www.me.com/ path/package.rpm

Управление пакетами

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

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

rpm -qip (пакет)

Все это замечательно, но, предположим, вы хотите узнать, что именно входит в состав данного пакета, из каких файлов он состоит? Да, вы можете просмотреть содержимое пакета во многом так же, как получить таблицу содержимого архива tar (с помощью tar -tvf):

rpm -qlp (пакет)

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

rpm -qa

Вам будет выдан список пакетов, установленных в системе.

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

rpm -V (пакет)

Проверить корректность всех пакетов, установленных в системе, тоже довольно просто:

rpm -Va

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

5 Сумма MD5; S Размер файла; L Символьная ссылка; T Время модификации; D Устройство; U Пользователь; G Группа; M Режим (включая права доступа и тип файла)

Иногда эти данные бессмысленны, например, если вы меняете файл /etc/inetd.conf, то размер и сумма MD5 будут изменяться. Однако некоторые вещи меняться не должны, такие как /bin/login. Команда rpm -Va может оказаться полезной для выполнения быстрой проверки защиты, позволяя понять, на что именно в первую очередь следует обратить внимание.

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

rpm -U (пакет)

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

rpm -F (пакет)

В этом случае будут модифицированы только установленные пакеты, и, если пакет не найден, то устанавливаться он не будет.

Модификация тоже выполняется весьма интересным образом. Сначала устанавливается новая версия и отмечаются ее отличия от старой. Затем старая версия удаляется, но только отдельные ее части так, чтобы не затронуть новые компоненты. Представьте, если /usr/local/bin/netscape был изменен, а затем удален, то все усилия пропали бы даром!

Удаление пакетов

Вы можете устанавливать, обновлять и управлять пакетами и, конечно же, вы можете деинсталлировать пакеты с помощью RPM. Чтобы «безоговорочно» удалить пакет RPM, используйте:

rpm -e (пакет)

В отличие от установок и модернизаций, при удалении для указания пакета следует использовать не название «пакет-версия.i386.rpm», а просто «пакет-версия». Это имена, которые выводятся на экран в режиме запроса и именно их и следует указывать. Вы должны дать менеджеру пакетов возможность удалить все компоненты пакета, указав самую общую часть имени, например, для linuxconf и linuxconf-devel это будет linuxconf. Можно также обойтись без зависимостей:

rpm -e -nodeps (пакет)

Здесь вы вновь берете риск на себя, поскольку можете в итоге удалить больше, чем рассчитываете. Можно, как и при установке, добавить флаги, чтобы получить более детальную информацию.

Некоторые замечания о RPM

Иногда разработчики создают довольно странные зависимости для своих RPM-пакетов. Возьмем, к примеру, libsafe. Он имеет четко определенную зависимость: itself («сам от себя»). В этом случае корректно установить пакет можно только с флагом -nodeps. В другой раз пакет может содержать дополнительные фрагменты, и, возможно, придется устанавливать больше, чем вы рассчитывали.

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

RPM можно использовать с любым вариантом Linux/Unix, поскольку он распространяется в исходных текстах. RPM распространяется в рамках Red Hat Linux и некоторых производных от него дистрибутивах. Рекомендуется использовать версии 3.0 и выше, чтобы обеспечить совместимость. Версия 4.0, как сообщается, имеет другой формат базы данных, поэтому я рекомендую разобраться, как разрешить эту проблему, прежде чем модернизировать свой RPM до версии 4.0. Не уверен, что для этого достаточно просто реконструировать базу данных в 4.0.

RPM обычно сам распространяется как RPM-пакет. Понятно? К счастью, он также поставляется и в виде архива, подготовленного с помощью gzip tarball, и непосредственно в исходных текстах. У меня, к примеру, RPM установлен на Slackware, но его можно установить и на SGI Irix или Sun Solaris, если потребуется. Впрочем, он практически бесполезен на других платформах помимо Linux, поскольку для других вариантов Unix пакеты готовятся средствами RPM крайне редко.

Хосе Назарио - аспирант факультета биохимии университета Case Western Reserve University. Он работает с Unix почти десять лет, а с Linux - с версии ядра 1.2.

Copyright (c) Хосе Назарио. Данный материал распространяется в соответствии с правилами и условиями, определяемыми «Лицензией на Открытые Публикации» (см. ее текст по адресу http://wwww.opencontent.org/openpub/ ). Jose Nazario, Using RPM: The Basics (Part I). Linux Gazette, Issue 68, July 2001 (www.linuxgazette.com ). Перевод на русский язык: Галина Никитина, сентябрь 2001.

Ресурсы

Лучше всего начать с Web-сайта, посвященного RPM и расположенного по адресу http://www.rpm.org/ . Здесь вы найдете книгу Maximum RPM, в которой рассказывается, как использовать, создавать и даже программировать с помощью API-интерфейсов RPM. Страница помощи RPM (rpm -h) также достаточно полезна, если знать некоторые основы. Архивы RPM можно найти по адресу http://www.rpmfind.net/ , где поддерживается большая база данных поиска пакетов для множества вариантов и версий на различных платформах. Крайне полезно.