Текущая версия на 16:18, 1 февраля 2019

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

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

Содержание

1 Предисловие
2 Установка программного обеспечения
- 2.1 Основы
- 2.2 Сборка пакетов для ROSA Desktop
3 Предварительные задачи
- 3.1 Создание требуемых папок
- 3.2 Не создавайте файл .rpmmacros
4 Сборка RPM
5 Проверка RPM-пакета
6 Что-то пошло не так?
7 Предустановочные и постустановочные сценарии
- 7.1 Основы
- 7.2 Работа с обновлениями
8 Файловые триггеры
9 More macros
10 Interaction with urpmi and rpmdrake
11 Группы пакетов ROSA
12 Лицензии
13 Alternative: checkinstall
14 Некоторые ссылки
- 14.1 RPM
- 14.2 Использование diff и patch

Предисловие

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

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

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

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

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

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

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

Важно различать с самого начала пакеты с исходным кодом .src.rpm, и бинарные пакеты (пакеты, содержащие двоичный код) .<archtype>.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 можно настроить таким образом, чтобы она сама загружала «исходники».

Например:

[camille@kenobi ~/rpm]$ rpm -i /cooker/SRPMS/ktron-1.0.1-2mdv.src.rpm 
[camille@kenobi ~/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:

[camille@kenobi ~/rpm]$ cd ~/rpm/SPECS
[camille@kenobi ~/rpm]$ rpmbuild -ba ktron.spec
[camille@kenobi ~/rpm]$ ls -l ~/rpm/RPMS/i586/ktron-1.0.1-2mdv.i586.rpm
[camille@kenobi ~/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/<package> или contrib-SPECS/<package>. К нему можно получить доступ на cvs.mandriva.com.

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

Допустим, вы нашли интересную программу на сайте Freshmeat или Sourceforge, и вы хотите, чтобы эта программа стала доступной для всех пользователей 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 <camille@mandrakesoft.com> 2.0.1-rosa2012
- Upgraded to 2.0.1 

* Mon Oct 25 1999 Camille Begnis <camille@mandrakesoft.com> 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 и не является обязательным, его использование строго рекомендуется, таким образом любой желающий сможет узнать, где можно скачать исходники.

Примечание
Информация о URL позволяет таким инструментам, как rpmbuildupdate, автоматически пересобирать новые версии программ (подробнее см. rpmbuildupdate).

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

Patch0:         gif2png-2.0.1-bugfix.patch

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

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

Все патчи должны находиться в каталоге 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 хранятся в специальных файлах, называемых <package>.po.

Эти файлы хранятся в poSPECS модуле в CVS Cooker. Когда создаётся новый пакет, основной po-файл автоматически создаётся в этом модуле для будущих переводов.

Этот метод подразумевает, что весь текст внутри спек-файла написал на английском языке. Однако, есть пакеты, предназначенные для определённых языков (например, ispell-de). В этом случае рекомендуется наличие текста на двух языках: на английском и на языке, для которого предназначен этот пакет. Для этого надо будет использовать специальные теги: Summary(de): .. и %description -l de.

Раздел подготовки к сборке (prep)

%prep  
%setup -q -a 1
%patch0 -p1

В этом резделе записан первый сценарий, выполняемый программой rpm. Он делает следующее:

создаёт каталог верхнего уровня для сборки (в BUILD);
распаковывает оригинальный исходный код в каталог сборки;
применяет патчи (если они есть) к исходному коду.

%setup -q -a 1

Это встроенный макрос, который выполняет следующие действия:

переходит в дерево сборки;
распаковывает исходный код (-q означает, что распаковка сопровождается минимальным выводом информации);
изменяет владельца и права доступа к файлам с исходным кодом.

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

Есть и другие интересные возможности при использовании макроса %setup:

-c name — переключатель -с говорит, что сначала должен создаваться каталог, и только затем должен осуществляться переход в этот каталог и происходить распаковка Source0. Это может оказаться полезным в том случае, если пакет tar.bz не имеет родительского каталога.
-D — не удалять каталог перед распаковкой. Полезно лишь при наличии более одного макроса setup. Может использоваться только в setup-макросах, следующих за первым (но в первом — никогда).
-T — этот параметр перекрывает действие по умолчанию распаковки Source из tar-архива и требует -b 0 или -a 0 для получения распакованного главного файла исходного кода. Этот параметр Необходим при наличии вторичных исходников.
-n name — используйте этот переключатель, если имя rpm-пакета отличается от имени, получаемого при распаковке Source. Например: если имя rpm-пакета program-version-revision, а Source распаковывается в program-version-date, процесс сборки rpm не сможет перейти в каталог program-version, поэтому используйте -n program-version-date, тогда rpm будет знать о новом каталоге, в котором и следует продолжить работу.

%patch0 -p1

Макрос, ответственный за применение патчей к исходникам. Его параметр -p<num> передаётся патч-программе. Допустим, что у вас есть другой патч Patch1, объявленный в разделе header, в таком случае вы должны будете добавить строку %patch1 -p1. Добавление команды -b .your_suffix является хорошим тоном, ведь таким образом вы можете сообщить другим, что делает ваш патч, или кто выполнил патч. Например, если Вася сделал патч, то он мог бы написать %patch -p1 -b .vasya, или, если патч сделал Петя, тогда это могло бы быть %patch -p1 -b .petya.

Раздел сборки (build)

%build

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

%configure

Эта строка используется для настройки исходников. Макрос %configure запускает команду ./configure со множеством дополнений таких, как

export CFLAGS="$RPM_OPT_FLAGS"

перед началом настройки (configure), и параметрами такими, как

i586-mandrake-linux --prefix=/usr --datadir=/usr/share

и т. д.

Иногда такие аргументы не поддерживаются сценарием configure. В таком случае, найдите причину и запустите ./configure с соответствующими параметрами. С помощью %{targetplatform} сообщите о целевой платформе вызову configure, если это поддерживается. Конечно, нужно избегать определения архитектуры в спек-файле; для x86 она будет определена в i586-mandrake-linux, как показно в примере выше.

Примечание
Чтобы использовать макрос %configure с разделяемыми библиотеками, понадобится пакет libtool.

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

%make

Это простой макрос, который подготоваливает в основном make с соответствующими мультипроцессорными параметрами -j<num>.

Для исходников, использующих xmkmf, вы должны заменить следующий make этим:

make CDEBUGFLAGS="$RPM_OPT_FLAGS" CXXDEBUGFLAGS="$RPM_OPT_FLAGS"

Для других пакетов, в большинстве случае (но не во всех) будет работать и просто make.

Раздел установки (install)

%install

В этом разделе должен содержаться сценарий, отвечающий за фактическую установку пакета в симулируемый установочный каталог: %{buildroot}.

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

%makeinstall

Это строка устанавливает программу в симулируемый установочный каталог для autoconf-исходников. Этот макрос будет расширен до "make install" со множеством параметров для установки в симулируемый каталог %{buildroot}, например,

prefix=%{buildroot}%{_prefix} bindir=%{buildroot}%{_bindir}

и т. д.

В некоторых случаях сценарий configure может быть частично поломан. Возможно, вам понадобится погрузится в Makefile'ы, чтобы найти дополнительные параметры, чтобы установить его правильно. Один из наиболее распространённых: иногда вам нужно использовать make DESTDIR=%{buildroot} install.

Чтобы сохранить место на жёстком диске и время загрузки, ROSA использует lzma для сжатия man и info страниц. Это делается автоматически инструментарием rpm.

Раздел очистки (clean)

Не используйте раздел clean в spec-файлах ROSA. При необходимости, используйте rpmbuild --clean ....

Раздел файлов (files)

%files

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

Список файлов должен быть написан в спек-файле вручную. Он может быть создан из списка файлов, созданных программой rpm в дереве каталога сборки. Чтобы создать список, наберите команду rpmbuild -bi mypackage.spec, процесс сборки остановится сразу после симулируемой установки. Затем, просмотрите каталог симулируемой установки (в нашем случае ~/rpm/tmp/gif2png-buildroot), чтобы увидеть, какие файлы предполагается положить в пакет (чаще всего кладутся все файлы).

Вы никогда не должны использовать find для получения списка файлов пакета; необходимо явно перечислять все файлы, что позводит избежать ошибок при сборке новых версий ПО. Единственным исключением являются файлы локализации, для которых следует использовать %find_lang %{name} в разделе %install и добавить %files -f %{name}.lang в секцию %files (см. описание макросов ниже).

Замечание о структуре каталогов: установленные файлы пакета должны следовать рекомендациям FHS http://www.pathname.com/fhs.

%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*

Рекомендуется перечислять в отдельности каждую man или info-страницу.

Также, вы можете задаться вопросом: почему вместо 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 <camille@mandrakesoft.com> 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 мой_пакет.<archtype>.rpm для получения отчёта об определённом пакете. Чтобы получить более подробную информацию, используйте ключ -i. Вы должны проверить rpm и src.rpm. Дополнительную информацию по ошибкам, которые встречаются при сборке, можно найти на странице проблемы сборки пакетов.

Install test

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

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

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

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

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

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

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

Таблица A-1. Значение параметра, передаваемого pre и post скриптам
Параметр \ Скрипт	%pre	%post	%preun	%postun
первоначальная установка	1	1	N/C	N/C
обновление	2	2	1	1
удаление	N/C	N/C	0	0

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

Для скриптов установки (%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<num>, распараллеливая сборку на многоядерных машинах. Если вам все-таки необходимо вызвать скрипт ./configure напрямую, никогда не указывайте название целевой аппаратной архитектуры. Для этих целей есть макрос %{targetplatform} (или даже %{targetcpu} , если необходима более точная информация).
Сборка серверного ПО. Для сборки, от которого требуется повышенная надежность в ущерб производительности, мы используем специальный макрос %serverbuild, который необходимо вызвать до начала самой сборки. Этот макрос выставляет необходимые значения флагов оптимизации. Секция %build при этом выгдядит следующим образом:

%build
%serverbuild
%configure
%make

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

%post
%_post_service <initscript-name>

%preun
%_preun_service <initscript-name>

Обработка 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/<key>.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

Использование diff и patch

Использование diff и patch

@@ Строка 9: / Строка 9: @@
 Этот документ построен таким образом, чтобы провести читателя шаг за шагом к получению rpm-пакета, который смог бы хорошо интегрироваться в ROSA Desktop.
-Настоятельно рекомендуем ознакомиться с [[Development/Howto/Participate|процессом разработки дистрибутива ROSA Desktop]].
+В первом приближении, '''RPM''' обозначает три понятия:
-Грубо говоря, '''RPM''' обозначает три понятия:
 * программу, предназначенную для установки или создания пакетов;
@@ Строка 29: / Строка 27: @@
 С точки зрения программиста, программа {{программа|rpm}} — упаковщик, скрывающий в одном единственном rpm-файле всю информацию, необходимую для установки программы на данную платформу.
-Важно различать с самого начала пакеты с исходным кодом {{файл|.src.rpm}}, и бинарные пакеты (пакеты, содержащие двоичный код) {{файл|.<archtype>.rpm}}.
+Важно различать с самого начала пакеты с исходным кодом {{File|.src.rpm}}, и бинарные пакеты (пакеты, содержащие двоичный код) {{File|.<archtype>.rpm}}.
 Первые содержат полное дерево исходного кода, т. е. кода написанного программистом, плюс весь материал, добавленный упаковщиком, необходимый для настройки, компиляции и установки программы. Как правило, этот материал состоит из спек-файла и патчей (если они есть).
-Вторые содержат откомпилированный бинарный код и все файлы (документация, файлы настроек, пиктограммы, ...), которые должны установливаться на целевой системе. Он также содержит процедуру, используемую для помещения файлов в соответствующие каталоги файловой системы, и действия, которые необходимо выполнить, чтобы получить нормально функционирующую программу.
+Вторые содержат откомпилированный бинарный код и все файлы (документация, файлы настроек, пиктограммы, ...), которые должны устанавливаться на целевой системе. Он также содержит процедуру, используемую для помещения файлов в соответствующие каталоги файловой системы, и действия, которые необходимо выполнить, чтобы получить нормально функционирующую программу.
 = Установка программного обеспечения =
@@ Строка 39: / Строка 37: @@
 == Основы ==
-Хотя изначально программа {{программа|rpm}} была разработана для дистрибутива [http://www.redhat.com Red Hat Linux], она также работает и в других дистрибутивах, основанных на rpm: [http://www.mandrivalinux.com Mandriva Linux], [http://www.suse.com/index_us.html Suse], [http://www.conectiva.com/ Conectiva] и т. д.; на всех этих системах программа {{программа|rpm}} уже установлена.
+Хотя изначально программа {{программа|rpm}} была разработана для дистрибутива [http://www.redhat.com Red Hat Linux], она также работает и в других дистрибутивах, основанных на rpm: [http://www.openmandriva.org OpenMandriva], [http://www.suse.com/index_us.html Suse], [http://www.getfedora.org Fedora] и т. д.; на всех этих системах программа {{программа|rpm}} уже установлена.
-«Чистый» дистрибутив (т. е. оригинальная непропатченная версия) программы {{программа|rpm}} можно получить здесь: [ftp://ftp.rpm.org/pub/rpm/dist/ ftp://ftp.rpm.org/pub/rpm/dist].
+Бинарный rpm-пакет, который вы будете собирать для ROSA, может не работать в других дистрибутивах.
-Бинарный rpm-пакет, который вы будете собирать для ROSA может не работать в других дистрибутивах, хотя разработчики делают всё возможное, чтобы дистрибутив оставался совместимым с Red Hat (а следовательно, и Fedora).
 == Сборка пакетов для ROSA Desktop ==
-Сборка пакетов для Cooker (т. е. разрабатываемой версии ROSA Desktop) всегда сопровождается применением патчей и прочих улучшений со стороны {{программа|rpm}}. Перед началом сборки, убедитесь, что в системе установлены все перечисленные ниже пакеты:
+Сборка пакетов для Cooker (т. е. разрабатываемой версии ROSA Desktop) всегда сопровождается применением патчей и прочих улучшений со стороны {{программа|rpm}}. Перед началом сборки убедитесь, что в системе установлены все перечисленные ниже пакеты:
+<pre>
+$ sudo urpmi rpm rpm-build spec-helper libtool rpmlint
+</pre>
-* {{Pkg|rpm}} — пропатченная версия программы Red Hat;
+* {{Pkg|rpm}} — сам rpm;
 * {{Pkg|rpm-build}} — содержит сценарии, используемые при сборке пакетов;
 * [[Development/Howto/Spec-Helper|{{Pkg|spec-helper}}]] — инструмент для минимализации спек-файлов с помощью некоторой автоматизации: разбор бинарных файлов, сжатие страниц руководств (man-страниц);
@@ Строка 81: / Строка 81: @@
 == Не создавайте файл {{File|.rpmmacros}} ==
-Ряд руководств по сборке пакетов RPM советуют создать в «домашнем» каталоге файл конфигурации {{File|.rpmmacros}} с персональной информацией, которая будет добавлена в метаданные пакета, такой как значения %packager, %vendor и другие. Не делайте этого. Все подобные поля заполняются автоматически системой сборки.
+Ряд руководств по сборке пакетов RPM советуют создать в «домашнем» каталоге файл конфигурации {{File|.rpmmacros}} с персональной информацией, которая будет добавлена в метаданные пакета, такой как значения %packager, %vendor и другие. Не делайте этого. Все подобные поля заполняются автоматически системой сборки. Однако, Вы все-таки можете создать этот файл, если Вы хотите указать другую директорию для сборки, отличную от /home/user/rpm. В этом случае укажите значения только для %_topdir и %_tmppath макросам. Не указывайте значения для других макросов.
 = Сборка RPM =
@@ Строка 97: / Строка 97: @@
 <strike>* '''media/jpackage'' для бинарных rpm noarch.</strike> (jpackage нет)
-Чтобы измененить source rpm для ROSA Linux, введите команду {{Cmd|rpm -ivh мой_пакет.src.rpm}}. Эта команда установит все файлы с исходными кодами в созданный вами каталог {{File|~/rpm}}.
+Чтобы изменить source rpm для ROSA Linux, введите команду {{Cmd|rpm -ivh мой_пакет.src.rpm}}. Эта команда установит все файлы с исходными кодами в созданный вами каталог {{File|~/rpm}}.
 {{Примечание|Программу ''urpmi'' можно настроить таким образом, чтобы она сама загружала «исходники».}}
@@ Строка 145: / Строка 145: @@
 === Предварительные проверки ===
-; Лицензия: Несмотря на распространённость лицензии GPL, есть ещё множество не-GPL лицензий. Необходимо точно определить лицензию программного обеспечения, чтобы узнать, можно ли включать его в дистрибутив. Мы не принимаем программы, использующие проприетарные лицензии, но для клуба есть несколько исключений. Также, мы не можем принять программы, которые не позволяют нам свободно их распространять. Список лицензий, которые разрешены к использованию в дистрибутиве, находится на странице [[Development/Packaging/Licenses|лицензии Mandriva]].
+; Лицензия: Несмотря на распространённость лицензии GPL, есть ещё множество не-GPL лицензий. Необходимо точно определить лицензию программного обеспечения, чтобы узнать, можно ли включать его в дистрибутив. Мы не принимаем программы, использующие проприетарные лицензии, но для клуба есть несколько исключений. Также, мы не можем принять программы, которые не позволяют нам свободно их распространять. Список лицензий, которые разрешены к использованию в дистрибутиве, находится на странице [http://wiki.mandriva.com/ru/Development/Packaging/Licenses|лицензии Mandriva].
 ; Сжатие tar-архива: Мы рекомендуем использовать исходный tar-архив без каких-либо изменений. Если исходники распространяются с использованием различных методов сжатия, мы часто отдаём предпочтение {{File|.tar.bz2}}. Избегайте сжатия патчей (полученные {{программа|diff}} и др. подобными программами) и других текстовых файлов (файлы настроек, сценарии и т. д.), т. к. они занимают, как правило, очень мало места, в противном случае будет сложнее увидеть изменения в файлах различий (diff-файлах) Subversion (Subversion в свою очередь сам использует некоторую форму сжатия).
@@ Строка 161: / Строка 161: @@
 Мы рассмотрим основные возможности, используемые в одном из спек-файлов. По мере того, как вы будете собирать всё больше и больше rpm-пакетов, вы поймёте, что существуют некоторые дополнительные параметры, о которых мы не рассказывали. Более подробную информацию можно получить в книге [http://rikers.org/rpmbook/ Maximum RPM] (см. раздел 7).
-{{Примечание|Мы рекомендуем открыть пару спек-файлов, чтобы  посмотреть, как они работают. Список спек-файлов и патчей можно получить [http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/ здесь]. Вы можете взять [[Development/Packaging/Tools/skel.spec|шаблон для спек-файла]], чтобы начать изучение с чистого листа.}}
+{{Примечание|Мы рекомендуем открыть пару спек-файлов, чтобы  посмотреть, как они работают. Список спек-файлов и патчей можно получить [https://abf.io/import/ здесь]. Вы можете взять [http://wiki.rosalab.ru/en/index.php/Template_Spec_Files шаблоны для спек-файлов], чтобы начать изучение с чистого листа.}}
 Рассмотрим следующий пример спек-файла, взятого из Cooker:
 <pre>
-%define name    gif2png
+Name:           gif2png
-%define version 2.0.1
-%define release %mkrel 1
-Name:           %{name}
 Summary:        Tools for converting websites from using GIFs to using PNGs
-Version:        %{version}
+Version:        2.0.1
-Release:        %{release}
+Release:        1
 Source0:        http://www.tuxedo.org/~esr/gif2png/%{name}-%{version}.tar.bz2
-Source1:        %{name}-%{version}-mdk-addon.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
-BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-buildroot
 License:        MIT-like
 Requires:       python
@@ Строка 198: / Строка 193: @@
 %install
-rm -rf $RPM_BUILD_ROOT
 %makeinstall
-%clean
-rm -rf $RPM_BUILD_ROOT
 %files
@@ Строка 212: / Строка 203: @@
 %{_bindir}/web2png
+# При подготовке пакетов для ROSA не создавайте раздел %changelog самостоятельно!
 %changelog
-* Mon Nov 02 1999 Camille Begnis <camille@mandrakesoft.com> 2.0.1-1mdk
+* Mon Nov 02 1999 Camille Begnis <camille@mandrakesoft.com> 2.0.1-rosa2012
 - Upgraded to 2.0.1
-* Mon Oct 25 1999 Camille Begnis <camille@mandrakesoft.com> 2.0.0-1mdk
+* Mon Oct 25 1999 Camille Begnis <camille@mandrakesoft.com> 2.0.0-rosa2012
 - Specfile adaptations for Mandrake
 - add python requirement
@@ Строка 231: / Строка 223: @@
 <pre>
-%define name    gif2png
+Name:     gif2png
-%define version 2.0.1
+Version:  2.0.1
-%define release 1
+Release:  1
 </pre>
-Эти три строки определяют константы, которые можно использовать в других разделах спек-файла. называемые {{macro|%{name} }}, {{macro|%{version} }} и {{macro|%{release} }}. Некоторые пакеты могут ормировать релиз с помощью устаревшего макроса {{macro|%mkrel}}, который в дистрибутивах ROSA просто возвращает свой аргумент.
+Эти три строки автоматически определяют константы, которые можно использовать в других разделах спек-файла, называемые {{macro|%{name} }}, {{macro|%{version} }} и {{macro|%{release} }}. Некоторые пакеты могут формировать релиз с помощью устаревшего макроса {{macro|%mkrel}}, который в дистрибутивах ROSA просто возвращает свой аргумент.
-Далее, мы можем заполнить некоторые информационные поля для {{программа|rpm}}:
+Кроме того, есть несколько тегов, о которых вы, возможно, захотели бы узнать, но которых нет в примере спек-файла. Есть некоторые теги, которые вы можете встретить. Никто не требует, чтобы вы помнили все теги, если вы только приступили к сборке rpm-пакетов, но после некоторого времени этот список может послужить хорошей отправной точкой!
-<pre>
-Name:           %{name}
-</pre>
-Значение поля '''Name''' используется в качестве имени пакета, а также в базе данных пакетов. Помните, что {{Процесс|%{name} }} является ссылкой на предыдущее определение.
-<pre>
-Version:        %{version}
-Release:        %{release}
-</pre>
 Теперь настало время объяснить, как формируется имя пакета. Очень важно всегда следовать этому соглашению, чтобы ваша работа была понятной для остальных.
-Кроме того, есть несколько тэгов, о которых вы возможно захотели бы узнать, но которых нет в примере спек-файла. Есть некоторые тэги, которые вы можете встретить. Никто не требует, чтобы вы помнили все тэги, если вы только приступили к сборке rpm-пакетов, но после некоторого времени этот список может послужить хорошей отправной точкой!
 * Бинарный пакет обозначается следующим образом: {{Pkg|имя-версия-релиз.arch.rpm}} (''name''-''version''-''release''.arch.rpm)
@@ Строка 274: / Строка 253: @@
 </pre>
-Эта строка говорит {{программа|rpm}}, какой файл исходного кода должен быть использован для сборки пакета. Заметьте, что имени файла предшествует полный URL (что, в общем случае, не обязательно), указывающий на веб-сайт, на котором расположен оригинальный исходный код. {{программа|rpm}} уберёт URL, сохранив только имя файла, и произведёт поиск в каталоге {{File|SOURCES}}. Хотя предоставление полного URL и не является обязательным, его использование строго рекомендуется, таким образом любой желающий сможет узнать, где можно скачать исходники. Кроме того, информация о URL позволяет таким инструментам, как {{программа|rpmbuildupdate}}, автоматически пересобирать новые версии программ (подробнее см. [[Development/Packaging/Tools/rpmbuildupdate|rpmbuildupdate]]).
+Эта строка говорит {{программа|rpm}}, какой файл исходного кода должен быть использован для сборки пакета. Заметьте, что имени файла предшествует полный URL (что, в общем случае, не обязательно), указывающий на веб-сайт, на котором расположен оригинальный исходный код. {{программа|rpm}} уберёт URL, сохранив только имя файла, и произведёт поиск в каталоге {{File|SOURCES}}. Хотя предоставление полного URL и не является обязательным, его использование строго рекомендуется, таким образом любой желающий сможет узнать, где можно скачать исходники.
 {{Примечание|Информация о URL позволяет таким инструментам, как ''rpmbuildupdate'', автоматически пересобирать новые версии программ (подробнее см. [[Development/Packaging/Tools/rpmbuildupdate|rpmbuildupdate]]).}}
@@ Строка 284: / Строка 263: @@
 </pre>
-Это не обязательный тэг. Его можно использовать в двух случаях:
+Это необязательный тег. Его можно использовать в двух случаях:
 # Вы исправили ошибку в исходном коде программы и [[Rpmbuild_and_git|создали патч]], который должен быть применён к исходному коду программы перед компиляцией.
@@ Строка 303: / Строка 282: @@
 Этот фрагмент говорит программе {{программа|rpm}}, в какой части дерева пакетов разместить наш пакет. Эта возможность используется фронт-эндами пакетных менеджеров таких, как {{программа|rpmdrake}} и {{программа|kpackage}}.
-Полная структура групп, которая, кстати говоря, отличается от аналогичных групп Red Hat, представлена на странице [[Development/Packaging/Groups|группы RPM]]. Очень важно следовать принятым соглашениям о группах, иначе ваш пакет внесёт неразбериху в дерево пакетов.
+Полная структура групп, которая, кстати говоря, отличается от аналогичных групп Red Hat, представлена на странице [[Packaging group]]. Очень важно следовать принятым соглашениям о группах, иначе ваш пакет внесёт неразбериху в дерево пакетов.
 <pre>
-BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-buildroot
+License:        MIT-like
 </pre>
-Эта строка является очень важной и её нельзя пропускать. Она говорит {{программа|rpm}}: чтобы установить программу, нужно использовать специальный корневой каталог (фиктивный {{File|/}}) на компьютере, где происходит компиляция. На то есть две причины:
+Этот тег определяет лицензию, выбранную держателем авторских прав, которая будет применяться к программному обеспечению, находящемуся в пакете. Чаще всего это GPL. На страницах [[Development/Packaging/Licenses|лицензии РОСА]] и [[Licensing policy|политика лицензирования]] представлены полные списки разрешённых к использованию лицензий.
-# При сборке пакета у вас нет доступа к ''root'', поэтому вы не можете установить пакет в нормальные каталоги.
-# Установка в рабочее дерево машины может смешать файлы пакетов с другими файлами, это может быть опасно, если пакет уже установлен. Множество людей использует {{File|/var/tmp}} или {{File|/tmp}} в качестве buildroot. Это не обязательно приведёт к каким-то проблемам, если вы являетесь единственным пользователем своего компьютера, но если пользователей несколько, и они одновременно компилируют один и тот же пакет в одно и то же время, {{программа|rpm}} будет «плеваться». Поэтому важно, чтобы вы определили {{macro|%{_tmppath} }} внутри своего собственного домашнего каталога!
 <pre>
-License:        MIT-like
+BuildRequires:   python
 </pre>
-Этот тэг определяет лицензию, выбранную держателем авторских прав, которая будет применяться к программному обеспечению, находящемуся в пакете. Чаще всего это — GPL. На страницах [[Development/Packaging/Licenses|лицензии Mandriva]] и [[Policies/Licensing|политика лицензирования]] представлены полные списки разрешённых к использованию лицензий.
+Обозначает, что для компиляции rpm потребуются библиотеки языка python, часто необходимо указывать, например, libpyglib-gi2, python-devel, если какой-то пакет не найти сразу, то можно поискать его с помощью команды urpmi -p ИмяПакета, так как он может содержаться в другом пакете, это указывается командой
+<pre>
+Provides:  libgif2png
+</pre>
+в Provides указывается имя библиотеки, которая может использоваться другими программами (предоставляется)
 <pre>
@@ Строка 324: / Строка 307: @@
 </pre>
-Эта строка была добавлена, потому что одна из программ, включённых в пакет, является сценарием написанным на языке программирования Python. Это означает, что сценарию для выполнения потребуется {{программа|python}}.
+Эта строка была добавлена, потому что одна из программ, включённых в пакет, является сценарием написанным на языке программирования Python. Это означает, что для корректной работы программы потребуется интерпретатор {{программа|python}}.
 Можно использовать требование к минимальной (или конкретной) версии. Например:
@@ Строка 332: / Строка 315: @@
 </pre>
-Ниже следует тэг описания:
+В редких случаях приложение может конфликтовать с другими уже установленными библиотеками или старыми версиями приложений, чтобы убрать их из системы при установке нужно сообщить об этом пользователю, для этого используется тег
+<pre>
+Conflicts: python <= 1.0.0
+</pre>
+Некоторые пакеты становятся устаревшими после установки новых библиотек, чтобы отметить их и удалить используется тег
+<pre>
+Obsoletes: gif2png < 2.0.0
+</pre>
+Ниже следует тег описания:
 <pre>
@@ Строка 341: / Строка 337: @@
 </pre>
-Это совершенно особый тэг внутри заголовочной части спек-файла, потому что он содержит текст, который может занимать произвольное количество строк и параграфов. Текст содержит полное описание программного обеспечения, которое помогает пользователю решить нужно ли устанавливать данный пакет или нет.
+Это совершенно особый тег внутри заголовочной части спек-файла, потому что он содержит текст, который может занимать произвольное количество строк и параграфов. Текст содержит полное описание программного обеспечения, которое помогает пользователю решить нужно ли устанавливать данный пакет или нет.
-В целях улучшения восприятия спек-файлов, переводы тэгов ''summary'' и '' description'' хранятся в специальных файлах, называемых {{File|<package>.po}}.
+В целях улучшения восприятия спек-файлов, переводы тегов ''summary'' и '' description'' хранятся в специальных файлах, называемых {{File|<package>.po}}.
 Эти файлы хранятся в [http://cvs.mandriva.com/cgi-bin/viewvc.cgi/poSPECS/ poSPECS модуле] в CVS Cooker. Когда создаётся новый пакет, основной po-файл автоматически создаётся в этом модуле для будущих переводов.
-Этот метод подразумевает, что весь текст внутри спек-файла написал на английском языке. Однако, есть пакеты, предназначенные для определённых языков (например, {{Pkg|ispell-de}}). В этом случае рекомендуется наличие текста на двух языках: на английском и на языке, для которого предназначен этот пакет. Для этого надо будет использовать специальные тэги: ''Summary(de)'': .. и {{Процесс|%description -l de}}.
+Этот метод подразумевает, что весь текст внутри спек-файла написал на английском языке. Однако, есть пакеты, предназначенные для определённых языков (например, {{Pkg|ispell-de}}). В этом случае рекомендуется наличие текста на двух языках: на английском и на языке, для которого предназначен этот пакет. Для этого надо будет использовать специальные теги: ''Summary(de)'': .. и {{Процесс|%description -l de}}.
 === Раздел подготовки к сборке (''prep'') ===
@@ Строка 426: / Строка 422: @@
 </pre>
-В этом разделе должен содержаться сценарий, отвечающий за фактическую установку пакета в симулируемый установочный каталог: {{File|$RPM_BUILD_ROOT}}.
+В этом разделе должен содержаться сценарий, отвечающий за фактическую установку пакета в симулируемый установочный каталог: {{File|%{buildroot}}}.
 Он должен содержать все команды, необходимые для того, чтобы сделать программу готовой к запуску на пользовательской системе.
-<pre>
-rm -rf $RPM_BUILD_ROOT
-</pre>
-Это - первая команда, которая должна быть выполнена в разделе {{macro|%install}}; она очищает каталог от предыдущей установки.
 <pre>
@@ Строка 440: / Строка 430: @@
 </pre>
-Это строка устанавливает программу в симулируемый установочный каталог для autoconf-исходников. Этот макрос будет расширен до "{{Cmd|make install}}" со множеством параметров для установки в симулируемый каталог {{File|$RPM_BUILD_ROOT}}, например, <pre>prefix=$RPM_BUILD_ROOT%{_prefix} bindir=$RPM_BUILD_ROOT%{_bindir}</pre> и т. д.
+Это строка устанавливает программу в симулируемый установочный каталог для autoconf-исходников. Этот макрос будет расширен до "{{Cmd|make install}}" со множеством параметров для установки в симулируемый каталог {{File|%{buildroot}}}, например, <pre>prefix=%{buildroot}%{_prefix} bindir=%{buildroot}%{_bindir}</pre> и т. д.
-В некоторых случаях сценарий configure может быть частично поломан. Возможно, вам понадобится погрузится в Makefile'ы, чтобы найти дополнительные параметры, чтобы установить его правильно. Один из наиболее распространённых: иногда вам нужно использовать make DESTDIR=$RPM_BUILD_ROOT install.
+В некоторых случаях сценарий configure может быть частично поломан. Возможно, вам понадобится погрузится в Makefile'ы, чтобы найти дополнительные параметры, чтобы установить его правильно. Один из наиболее распространённых: иногда вам нужно использовать make DESTDIR=%{buildroot} install.
-Чтобы сохранить место на жёстком диске и время загрузки, ROSA использует lzma для сжатия man и info страниц. Однако, этот аспект управляется непосредственно изменённой ROSA программой rpm.
+Чтобы сохранить место на жёстком диске и время загрузки, ROSA использует lzma для сжатия man и info страниц. Это делается автоматически инструментарием rpm.
-It is the same for old strip $RPM_BUILD_ROOT%{_bindir}/* || : lines: they have to be removed
+=== Раздел очистки (''clean'') ===
-Всё это делается для того, чтобы подготовить файлы для упаковки.
+''Не используйте'' раздел clean в spec-файлах ROSA. При необходимости, используйте {{cmd|rpmbuild --clean ...}}.
-<pre>
-%clean
-</pre>
-Этот раздел очищает дерево каталога сборки $RPM_BUILD_ROOT.
-This section is meant to clean the build directory tree, $RPM_BUILD_ROOT.
-<pre>
-rm -rf $RPM_BUILD_ROOT
-</pre>
 === Раздел файлов (''files'') ===
@@ Строка 472: / Строка 450: @@
 Список файлов должен быть написан в спек-файле вручную. Он может быть создан из списка файлов, созданных программой {{программа|rpm}} в дереве каталога сборки. Чтобы создать список, наберите команду {{Cmd|rpmbuild -bi mypackage.spec}}, процесс сборки остановится сразу после симулируемой установки. Затем, просмотрите каталог симулируемой установки (в нашем случае {{File|~/rpm/tmp/gif2png-buildroot}}), чтобы увидеть, какие файлы предполагается положить в пакет (чаще всего кладутся все файлы).
-Вы никогда не должны использовать {{программа|find}} для получения списка файлов чтобы включить, но точно список всех файлов (это выявит ошибки в новых версиях). Единственное исключение существует для локалей для которых вы должны использовать {{Процесс|%find_lang %{name} }} в разделе {{Процесс|%install}} и заменить {{Процесс|%files}} {{Процесс|%files -f %{name}.lang}}  (см. [[#More_macros|Appendix B]]).
+Вы никогда не должны использовать {{программа|find}} для получения списка файлов пакета; необходимо явно перечислять все файлы, что позводит избежать ошибок при сборке новых версий ПО. Единственным исключением являются файлы локализации, для которых следует использовать {{Процесс|%find_lang %{name} }} в разделе {{Процесс|%install}} и добавить {{Процесс|%files -f %{name}.lang}} в секцию {{Процесс|%files}} (см. описание макросов ниже).
-Note that you should never use find to build a list of files to include but explicitly list all files (this will show up bugs in new versions). The only exceptions is for locales for which you should use {{macro|%find_lang %{name} }} in the {{macro|%install}} section and replace {{macro|%files}} by {{macro|%files -f %{name}.lang}} (see [[#More_macros|Appendix B]]).
 Замечание о структуре каталогов: установленные файлы пакета '''должны''' следовать рекомендациям FHS [http://www.pathname.com/fhs http://www.pathname.com/fhs].
@@ Строка 482: / Строка 458: @@
 </pre>
-Этот тэг задаёт атрибуты, которые будут применяться ко всем файлам, копируемым в  систему пользователя. Аргументы означают:
+Этот тег задаёт атрибуты, которые будут применяться ко всем файлам, копируемым в систему пользователя. Аргументы означают:
 * -: все атрибуты для регулярных файлов остаются неизменными;
@@ Строка 493: / Строка 469: @@
 </pre>
-Специальный тэг {{Процесс|%doc}} помечает файлы, которые являются частью документации пакета. Файлы документации будут помещены в {{File|/usr/share/doc/gif2png-2.0.1/}}. Этот каталог будет создан автоматически. Файлы {{Процесс|%doc}} задаются относительно каталога извлечённых из tar-архива исходников в каталоге {{File|BUILD}}.
+Специальный тег {{Процесс|%doc}} помечает файлы, которые являются частью документации пакета. Файлы документации будут помещены в {{File|/usr/share/doc/gif2png-2.0.1/}}. Этот каталог будет создан автоматически. Файлы {{Процесс|%doc}} задаются относительно каталога извлечённых из tar-архива исходников в каталоге {{File|BUILD}}.
 <pre>
@@ Строка 502: / Строка 478: @@
 Рекомендуется перечислять в отдельности каждую man или info-страницу.
-Также, вы можете задаться вопросом: почему вместо {{File|gif2png.1.lzma}} используется {{File|gif2png.1*}}? Это сделано для того, чтобы сохранить совместимость с другими системами, которые используют сжатие gzip вместо lzma. Если вы нашли такие ссылки на lzma сжатие в спеке, замените их дикой картой. Чаще всего вы можете даже использовать {{macro|%{_mandir}/man1/*}}, что возьмёт все файлы, какие он смоет найти.
+Также, вы можете задаться вопросом: почему вместо {{File|gif2png.1.lzma}} используется {{File|gif2png.1*}}? Это сделано для того, чтобы сохранить совместимость с другими системами, которые используют сжатие gzip вместо lzma. Если вы нашли такие ссылки на lzma сжатие в спеке, замените их регулярным выражением, как в примере выше. Чаще всего вы можете использовать {{macro|%{_mandir}/man1/*}}, что соответствует всем файлам в директории man1.
-Also you may wonder why gif2png.1* was used instead of gif2png.1.lzma. This is done to preserve compatibility with other systems that could use gzip compression instead of lzma. If you find such referencies to lzma compression in spec files, change them to a wildcard. Most of the time you can even use {{macro|%{_mandir}/man1/*}}, this will take all the files it can find.
 <pre>
@@ Строка 512: / Строка 486: @@
 Как вы можете видеть, для каждого необходимого пути есть макрос нужного типа. Вот наиболее полезные:
-(взгляните на файл {{File|/usr/lib/rpm/macros}} для всего): {{Процесс|%{_prefix} }}, {{Процесс|%{_bindir} }}, {{Процесс|%{_sbindir} }}, {{Процесс|%{_datadir} }}, {{Процесс|%{_libdir} }}, {{Процесс|%{_sysconfdir} }}, {{Процесс|%{_mandir} }}, {{Процесс|%{_infodir} }}. Для игр используйте {{Процесс|%{_gamesbindir} }} и {{Процесс|%{_gamesdatadir} }}.
+(полный список доступен в файле {{File|/usr/lib/rpm/macros}}): {{Процесс|%{_prefix} }}, {{Процесс|%{_bindir} }}, {{Процесс|%{_sbindir} }}, {{Процесс|%{_datadir} }}, {{Процесс|%{_libdir} }}, {{Процесс|%{_sysconfdir} }}, {{Процесс|%{_mandir} }}, {{Процесс|%{_infodir} }}. Для игр используйте {{Процесс|%{_gamesbindir} }} и {{Процесс|%{_gamesdatadir} }}.
-As you can see, you have macros for every kind of path you need. Here are the most useful ones (look at the file {{file|/usr/lib/rpm/macros}} for everything) : {{macro|%{_prefix} }}, {{macro|%{_bindir} }}, {{macro|%{_sbindir} }}, {{macro|%{_datadir} }}, {{macro|%{_libdir} }}, {{macro|%{_sysconfdir} }}, {{macro|%{_mandir} }}, {{macro|%{_infodir} }}. For games, use {{macro|%{_gamesbindir} }} and {{macro|%{_gamesdatadir} }}.
 === Раздел журнала изменений (''changelog'') ===
@@ Строка 620: / Строка 592: @@
 = Проверка RPM-пакета =
-Для получения информации по этой теме вы должны обратиться к страницам [http://qa.mandriva.com/ Bugzilla].
 == Основные проверки ==
@@ Строка 632: / Строка 602: @@
 == Запуск Rpmlint ==
-После этого, вы должны воспользоваться утилитой [[Rpmlint]], которая выполнит различные проверки пакета. Наберите {{Cmd|rpmlint мой_пакет.<archtype>.rpm}} для получения отчёта об определённом пакете. Чтобы получить более подробную информацию, используйте ключ {{Cmd|-i}}. Вы должны проверить {{File|rpm}} и {{File|src.rpm}}. Дополнительную информацию по ошибкам, которые встречаются при сборке, можно найти на странице [[Problems and issues with packaging|проблемы сборки пакетов]].
+После этого, вы должны воспользоваться утилитой [[Rpmlint]], которая выполнит различные проверки пакета. Перед запуском {{Cmd|rpmlint}} убедитесь, что у вас установлен пакет {{pkg|rpmlint-mandriva-policy}}, содержащий правила проверки для Росы. Наберите {{Cmd|rpmlint мой_пакет.<archtype>.rpm}} для получения отчёта об определённом пакете. Чтобы получить более подробную информацию, используйте ключ {{Cmd|-i}}. Вы должны проверить {{File|rpm}} и {{File|src.rpm}}. Дополнительную информацию по ошибкам, которые встречаются при сборке, можно найти на странице [[Problems and issues with packaging|проблемы сборки пакетов]].
 == Install test ==
@@ Строка 680: / Строка 650: @@
 * ...
-== Dealing with upgrades ==
+== Работа с обновлениями ==
-The fact that a package may be upgraded, and not simply installed or removed, makes the thing a little bit tougher... The problem is that the {{macro|%postun}} script of the update is run after the {{macro|%post}} of the old version. So all {{macro|%post}} stuff is lost...
+Работа с пакетами осложняется тем фактом, что пакет может быть обновлен, а не просто установлен или удален. проблема заключается в том, что при обновлении скрипт {{macro|%postun}} новой версии пакета запускается после скрипта {{macro|%post}} старой версии, и то, что сделал последний скрипт, может быть потеряно.
-It is often useful to ensure that an action occurs only during an install and not during an upgrade. Likewise for an action that only occurs during an uninstall and not during an upgrade. RPM's mechanism for dealing with this is the argument that is passed to the {{macro|%pre}}, {{macro|%preun}}, {{macro|%post}} and {{macro|%postun}} scripts by default.
+Часто полезно убедиться, что те или иные действия производятся только при установке/удалении пакета, но не при обновлении. Для обработки таких ситуаций RPM передает специальный аргумент скриптам {{macro|%pre}}, {{macro|%preun}}, {{macro|%post}} и {{macro|%postun}}.
-This argument indicates the number of instances of this RPM that will be installed on the machine after the current script has completed.  For example, if a new package is installed then 1 will be passed to {{macro|%pre}} and 1 passed to {{macro|%post}}. When the package is upgraded, 2 will be passed to {{macro|%pre}} of the new RPM, 2 will be passed to {{macro|%post}} of the new RPM, 1 will be passed to {{macro|%preun}} of the old RPM and 1 will be passed to {{macro|%postun}} of the old package.
+Аргумент содержит количество  различных версий данного пакета, которые будут установлены на машине после выполнения данного скрипта. Например, при установке нового пакета, скриптам {{macro|%pre}} и {{macro|%post}} будет передано значение "1". При обновлении пакета, скрипты {{macro|%pre}} и {{macro|%post}} новой версии получат значение "2", скрипты {{macro|%preun}} и {{macro|%postun}} старой версии - "1".
 {| border="1"
-|+ align="bottom" style="font-size: 10px; font-weight: bold;" | Table A-1. Value of the parameter passed to pre and post scripts
+|+ align="bottom" style="font-size: 10px; font-weight: bold;" | Таблица A-1. Значение параметра, передаваемого pre и post скриптам
-! style="background:#efefef;" | Parameter \ Script
+! style="background:#efefef;" | Параметр \ Скрипт
 ! style="background:#efefef;" | %pre
 ! style="background:#efefef;" | %post
@@ Строка 696: / Строка 666: @@
 ! style="background:#efefef;" | %postun
 |-
-| for a first time install || 1 || 1 || N/C || N/C
+| первоначальная установка || 1 || 1 || N/C || N/C
 |-
-| for an upgrade || 2 || 2 || 1 || 1
+| обновление || 2 || 2 || 1 || 1
 |-
-| for a removal || N/C || N/C || 0 || 0
+| удаление || N/C || N/C || 0 || 0
 |}
-This will allow the programmer to distinguish different attitudes of his scripts depending on the operation: install or upgrade.
+Наличие такого параметра позволяет программистам различать, в какой ситуации запускается скрипт - при установке или при обновлении пакета.
-* For install scripts ( {{macro|%post}}, {{macro|%pre}} ) check if $1 is equal to "1" then it is a first time install, not an update.
+* Для скриптов установки ({{macro|%post}}, {{macro|%pre}}) - если параметр $1 равен "1", то происходит первоначальная установка
-* For uninstall scripts ( {{macro|%postun}}, {{macro|%preun}} ) check if $1 is equal to "0", if yes then it is a full removal; if not it is either an upgrade or an install --force of the same package.
+* Для скриптов удаления ({{macro|%postun}}, {{macro|%preun}}) - если параметр $1 равен "0", то происходит удаление пакета; иначе это обновление либо установка с опцией --force.
-To test this argument, the following 'if' statement is used:
+Для проверки значение параметра, можно использовать следующую конструкцию:
 <pre>
 %postun
-if [ $1 = 0 ]; then
+if [ $1 -eq 0 ]; then
-     // Do stuff specific to uninstalls
+     ### Выполнение действий, специфичных для удаления пакета
 fi
-if [ $1 = 1 ]; then
+if [ $1 -eq 1 ]; then
-     // Do stuff specific to upgrades
+     ### Выполнение действий, специфичных для обновления пакета
 fi
 </pre>
-A single test is therefore enough, to call the right action at the right time.
 = Файловые триггеры =
-Чтобы избавиться от необходимости выполнения часто встречающихся задач - таких как выполнение "%post -p /sbin/ldconfig" или "%update_menus" - в ROSA используются [[rpm filetriggers|файловые триггеры]].
+Чтобы избавиться от необходимости выполнения часто встречающихся задач - таких как выполнение "%post -p /sbin/ldconfig" или "%update_menus" - в ROSA используются [[файловые триггеры RPM]].
 = More macros =
-When building RPM's for Mandriva Linux, you have more macros to simplify the specfile.
+При сборке пакетов для Росы, вы можете использовать в spec-файле различные макросы для выполнения типичных задач.
-* Handling the info pages. An example is the best teacher:
+* Обработка info-старниц:
 <pre>
@@ Строка 740: / Строка 708: @@
 </pre>
-* The menu system. Starting with MandrivaLinux2007.0, [[Development/Howto/XDGMenuSystem|XDG Menu system]] is used, replacing the old [[Development/Howto/MenuSystem|Debian Menu system]].
+* Обновление системы меню. В Росе используется [[XDG_menu_system_policy|Меню XDG]].
 <pre>
@@ Строка 750: / Строка 718: @@
 </pre>
-* Handling internationalization cleanly. The best way is not to enter by hand the {{file|.mo}} files that usually are in {{file|/usr/share/locale/..}}, but to use a special macro in the {{macro|%install}} section, which will fill up a special file for that:
+* Обработка файлов локализации. Хорошей практикой является не ручное перечисление всех {{file|.mo}}-файлов, которые обычно находятся в поддиректориях {{file|/usr/share/locale/..}}, а использование специального макроса в секции {{macro|%install}}, которые создаст отдельный файл с перечнем файлов с локализациями:
 <pre>
@@ Строка 756: / Строка 724: @@
 </pre>
-Then you will use the file in the file list:
+Созданный файл необходимо указать в секции ''files'':
 <pre>
@@ Строка 762: / Строка 730: @@
 </pre>
-* Build macros. The build macros {{macro|%configure}} and {{macro|%makeinstall}} are quite big at the present time. They specify the prefix, but also every common directory (such as bindir, datadir, and so on); in that respect, they work flawlessly with small and medium sized packages, but always need some attention for the rest. The macro {{macro|%make}} performs the make command with appropriate {{cmd|-j<num>}} option to scale well with multiprocessors. If you need to call manually the {{prog|./configure}} script, remember to NEVER hardcode the architecture; the macro {{macro|%{''target''platform} }} is made for that purpose (or even {{macro|%{''target''cpu} }}, if necessary).
+* Макропопределения, используемые при сборке - {{macro|%configure}} и {{macro|%makeinstall}}. Они автоматически устанавливают префикс для установки, а также различные директории (такие как bindir, datadir и другие). Как правило, эти макросыф отлично работают с небольшими пакетами, но могут потербовать дополнительной настройке при сборке сложных продуктов. Макрос {{macro|%make}} вызывает команду make с соответствующей опцией {{cmd|-j<num>}}, распараллеливая сборку на многоядерных машинах. Если вам все-таки необходимо вызвать скрипт {{prog|./configure}} напрямую, ''никогда'' не указывайте название целевой аппаратной архитектуры. Для этих целей есть макрос {{macro|%{''target''platform} }} (или даже {{macro|%{''target''cpu} }}, если необходима более точная информация).
-* Building servers. To build safer servers, we use a specific macro, {{macro|%serverbuild}}, to be used before the actual build occurs. This allows for safer optimization flags. The {{macro|%build}} section will often look like:
+* Сборка серверного ПО. Для сборки, от которого требуется повышенная надежность в ущерб производительности, мы используем специальный макрос {{macro|%serverbuild}}, который необходимо вызвать до начала самой сборки. Этот макрос выставляет необходимые значения флагов оптимизации. Секция {{macro|%build}} при этом выгдядит следующим образом:
 <pre>
@@ Строка 772: / Строка 740: @@
 </pre>
-* Initscript macros. When you install a package which will provide it's own initscript (the files in the directory {{file|/etc/init.d}} ), it needs to be added through a call which looks like {{cmd|chkconfig --add ..}}, but not in the case of upgrades, and it needs to be restarted if already running; when uninstalling, similar (opposite) things must be done; we have specific macros to do that without a glitch:
+* Макросы для init-скриптов. При установке пакета, в котором содержится init-скрипт (файл в директории {{file|/etc/init.d}}), необходимо зарегистрировать этот скрипт вызовом {{cmd|chkconfig --add ..}}; при обновлении, этого делать не надо, но если скрипт работает, то он должен быть перезапущен; при удалении пакета, необходимо удалить информацию о скрипте. Для этих целей у нас есть соответсвующий макрос:
 <pre>
@@ Строка 782: / Строка 750: @@
 </pre>
-* Handling ghostfiles. Mostly with games, sometimes packages use a varying file which may even not be present. That's where ghostfiles are useful. Here's an example:
+* Обработка ''ghost''-файлов. Некоторые пакеты (в частности, многие игры), содержат файлы, которые в некоторый момент времени могут отсутствовать в системе. Такие файлы необходимо помечать как ''ghost'' и обрабатывать с помощью специальных макросов:
 <pre>
@@ Строка 789: / Строка 757: @@
 (...)
-mkdir -p $RPM_BUILD_ROOT/var/lib/games
+mkdir -p %{buildroot}/var/lib/games
-touch $RPM_BUILD_ROOT/var/lib/games/methanescores
+touch %{buildroot}/var/lib/games/powermanga.hi
 %post
@@ Строка 801: / Строка 769: @@
 </pre>
-The {{macro|%create_ghostfile}} macro will expand to:
+Макрос {{macro|%create_ghostfile}} будет развернут в следующую конструкцию:
 <pre>
@@ Строка 811: / Строка 779: @@
 </pre>
-* .desktop / MIME type mapping association : XDG menu system allows setting association between an application and a MIME type in {{file|.desktop}} file. The {{prog|update-desktop-database}} utility should be run if such {{file|.desktop}} file is installed / uninstalled on the system, using macros as shown in the following example:
+* Привязка типов фалов .desktop / MIME к приложениям: система меню XDG позволяет привязывать приложения к файлам с заданным MIME-типом в файлах {{file|.desktop}}. При установке или удалении {{file|.desktop}}-файла, необходимо запустить утилиту {{prog|update-desktop-database}}, используя соответствующие макросы:
 <pre>
@@ Строка 821: / Строка 789: @@
 </pre>
-* Freedesktop.org MIME type database : the database used to list all available MIME types, with magic and/or extension file pattern should be updated using macros as shown in the following example :
+* База данных MIME-типов Freedesktop.org: база данных, используемая для получения всех возможных типов MIME с соответствующими расширениями файлов или их "магическими" числами, должна обновляться посредством вызова следующих макросов:
 <pre>
@@ Строка 831: / Строка 799: @@
 </pre>
-* Icon cache : <b>all</b> packages shipping icons stored in {{file|/usr/share/icons/hicolor}} (or other freedesktop icon theme directories, such as {{file|/usr/share/icons/gnome}} or {{file|/usr/share/icons/crystalsvg}} ) <b>must</b> update icon cache, as stated below (icons stored in {{file|/usr/share/icons}}, {{file|/usr/share/icons/mini}} or {{file|/usr/share/icons/large}} are not concerned by this requirement) :
+* Кэш иконок: <b>все</b> пакеты, содержащие иконки, устанавливаемые в {{file|/usr/share/icons/hicolor}} (или другие директории, предусмотренные спецификациями freedesktop, - например, {{file|/usr/share/icons/gnome}} или {{file|/usr/share/icons/crystalsvg}} ) <b>должны</b> обновлять кэш иконок, как показано в следующем примере (данное требование не относится к иконкам, хранящимся в {{file|/usr/share/icons}}, {{file|/usr/share/icons/mini}} или {{file|/usr/share/icons/large}}):
 <pre>
@@ Строка 850: / Строка 818: @@
 </pre>
-* GConf schemas registration : GNOME GConf schemas must be installed / uninstalled using the following macros:
+* Регистрация схем GConf: Схемы GNOME GConf должны устанавливаться и удаляться с помощью следующих макросов:
 <pre>
 ...
-# each schema key here corresponds to a file named /etc/gconf/schemas/<key>.schemas
+# каждый ключ схемы соответствует файлу с именем /etc/gconf/schemas/<key>.schemas
 %define schemas apps_gnome_settings_daemon_default_editordesktop_gnome_font_rendering desktop_gnome_peripherals_keyboard_xkb fontilus themus
@@ Строка 864: / Строка 832: @@
 </pre>
-* Scrollkeeper database update: scrollkeeper database (used to index docbook documentation) should be updated when installing an {{file|.omf}} file like this:
+* Обновление бд scrollkeeper: если устанавливается файл {{file|.omf}}, то необходимо обновить базу данных scrollkeeper (используемую для индексирования документации в формате docbook):
 <pre>
@@ Строка 887: / Строка 855: @@
 = Лицензии =
-По вопросам, относящимся к лицензиям ПО, собираемого в пакеты, обращайтесь к [[Licensing_policy]].
+По вопросам, относящимся к лицензиям ПО, собираемого в пакеты, обращайтесь к [[Licensing policy]].
 = Alternative: checkinstall =
@@ Строка 897: / Строка 865: @@
 == RPM ==
-*  [http://arklinux.org/ark-rpm-howto.html Ark linux howto]
+*  [http://www.ibm.com/developerworks/linux/library/l-rpm1/index.html Статья IBM по сборке rpm]
-*  [http://www-106.ibm.com/developerworks/library/l-rpm1/ Статья IBM по сборке rpm]
 *  [http://www.redhat.com/magazine/002dec04/features/betterliving-part2/ Статья из журнала redhat по сборке rpm]
 *  [http://www.gurulabs.com/GURULABS-RPM-LAB/GURULABS-RPM-GUIDE-v1.0.PDF Учебное пособие в формате Pdf, созданное  GuruLabs, по сборке rpm]
 *  [http://fedora.redhat.com/docs/drafts/rpm-guide-en/ Руководство RPM Red Hat]
+*  [http://wiki.centos.org/HowTos/SetupRpmBuildEnvironment CentOS how to setup RPM Build Environment]
 == Использование diff и patch ==
 * [http://www.ylsoftware.com/news/243 Использование diff и patch]
-= Другие источники информации о Mandriva RPM =
-* [http://cybercfo.gkmweb.com/mandrake_a_la_gentoo-9.2.pdf "Mandrake a la Gentoo" руководство] от Cybercfo
 [[Категория:Управление пакетами]]
 [[Категория:Packaging Guidelines]]
+[[Категория:Инструменты_разработки]]
 [[en:Packaging_HowTo]]

Основы RPM — различия между версиями

Текущая версия на 16:18, 1 февраля 2019

Содержание

Предисловие

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

Основы

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

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

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

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

Сборка RPM

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

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

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

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

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

Раздел подготовки к сборке (prep)

Раздел сборки (build)

Раздел установки (install)

Раздел очистки (clean)

Раздел файлов (files)

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

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

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

Сборка

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

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

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

Запуск Rpmlint

Install test

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

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

Основы

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

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

More macros

Interaction with urpmi and rpmdrake

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

Лицензии

Alternative: checkinstall

Некоторые ссылки

RPM

Использование diff и patch

Навигация

Поиск