mikhailnov/rosa-building-guide

Инструкция по сборке пакетов для Росы. Создается сообществом. Коммиты приветствуются. Для визуального редактирования Markdown рекомендуем редактор Remarkable: https://remarkableapp.github.io/linux.html

СБОРКА И ОБНОВЛЕНИЕ ПРОГРАММ В ОС «РОСА Linux»

(Дидактические материалы)

Россия, 2017г. Автор: Владимир Шаронин

Введение. «Проба пера»

"Сделай сам"- Howto для желающих обновлять программы в РОСЕ

Запросов от пользователей на обновление тех или иных программ в дистрибутивах ROSA Desktop Fresh мы получаем не много, а очень много. Приходится закрывать слишком разросшиеся темы на форуме, разбивая их на более мелкие.

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

Итак, вы узнали о выходе новой версии вашей любимой программы и хотите обновить соответствующий пакет в РОСЕ. Для примера, возьмем набирающий популярность редактор **Atom **— у него недавно (16 Dec 2015 — прим. составителя) вышла версия 1.3.2, а в репозиториях РОСЫ на момент написания этой статьи — все еще версия 1.2.0. Давайте исправим это досадное недоразумение.

Первым делом идем и регистрируемся в нашей среде сборки http://abf.io/, если вы этого до сих пор не сделали. Для этого кликаем в правом верхнем углу на «Регистрацию», вводим логин/пароль и успешно заходим в систему (регистрация абсолютно свободна, происходит мгновенно и не требует никаких подтверждений).

Теперь находим с помощью поиска* интересующий нас пакет atom, находящийся в группе import (обязательно используйте эту группу, именно из нее собираются пакеты в официальные репозитории!).

*Прим. составителя: удобнее сразу использовать поиск по ссылке https://abf.io/import. Также в настройках (шестерёнка справа сверху) можно выбрать язык Russian, тогда некоторые кнопки станут выглядеть иначе.

Переходите в этот проект и жмите кнопку «Клонировать» («Fork»).

В появившемся окне выберите опцию «Клонировать в <ваш_логин>/atom» («Fork to <your_login>/atom»). Этим действием вы склонируете проект в ваш персональный репозиторий, где вы сможете с ним играться в свое удовольствие. Клонирование происходит достаточно быстро, и вы сразу будете перенаправлены на страницу склонированного проекта. Если вы видите сообщение о том, что репозиторий пуст — просто обновите страницу.

Следующим пунктом необходимо изменить используемую ветку Git-репозитория на rosa2014.1. Если эта фраза вам ни о чем не говорит, не пугайтесь — достаточно в выпадающем списке в правом верхнем углу выбрать значение «rosa2014.1» (мы используем эту ветку, начиная с релиза ROSA Desktop Fresh R4 и точно продолжим использовать в R7).

Теперь вам необходимо в списке файлов проекта найти файл с расширением «spec» («atom.spec» в нашем случае) и кликнуть на него и затем кликнуть на «Edit» для его редактирования.

Все, что вам надо изменить в этом файле — это значение тэга Version, который обычно находится где-то вверху файла. Как мы видим, сейчас здесь указана версия 1.2.0, и мы ее заменим на 1.3.2. После этого в окне «Commit message» оставьте некоторое разумное описание произведенных изменений — например, «Updated to version 1.3.2». На этом всё — теперь файл можно сохранить соответствующей кнопкой внизу экрана.

Если кто-то подумал, что этим мы и обновили программу в дистибутиве — спешим огорчить, мы всего лишь подготовились к попытке собрать новую версию, и теперь пора эту попытку произвести. Для этого кликаем на кнопку «New Build», и в появившемся окне выполняем два действия:

• на всякий случай, отключите ваш персональный репозиторий — вдруг там уже есть что-то, что помешает чистоте сборки
• если вы собираете пакет для репозитория Contrib (или просто не уверены, в какой репозиторий вы его собираете), то обязательно отметьте в левой колонке позицию «contrib» в секции «rosa2014.1»

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

Если новая программ работает как положено, то надо поделиться своими достижениями с остальными членами сообщества (ведь вы помните, что до сих пор мы все действия производили в вашем персональном репозитории?), послав запрос на обновление в основной проект, находящийся в группе import. Делается это посредством нажатием на кнопку «Pull Request» на страничке вашего проекта.

В появившемся окне убедитесь, что для исходного и целевого проектов выбрана ветка rosa2014.1, при необходимости нажмите кнопку «Update commits», оставьте некоторое вразумительное сообщение в поле Description и отправьте запрос, нажав на кнопку «Send Pull Request».

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

Ложка дёгтя

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

Когда ABF начинает сборку пакета, он в качестве одного из предварительных шагов извлекает все файлы, необходимые для сборки — например, архивы с исходным кодом. Все такие файлы указаны в тэгах Source spec-файла проекта. В этих тэгах можно указывать ссылки (URL) на внешние ресурсы, и если ABF не сможет найти нужные файлы в Git-репозитории либо в своем хранилище бинарных файлов, то он попробует скачать файл по ссылке.

Как следствие, изложенный выше подход сработает только для проектов, у которых правильно заполнены тэги Source. Если вы посмотрите в файл atom.spec из нашего примера, то увидите там такую строку:

Source0: https://github.com/atom/atom/archive/v%{version}.zip

Здесь приведена ссылка на архив с исходным кодом на github, причем вместо фиксированной версии указан макрос version, который автоматически разворачивается в значение тэга Version. Именно поэтому для сборки новой версии вам достаточно обновить значение этого тэга — дальше система сборки сама отправится скачивать архив с новым исходным кодом. И именно поэтому мы стараемся поддерживать значения тэгов Source в актуальном состоянии. (Но в случае, когда авторская ссылка предполагает именно ручное копирование исходника, либо вообще не существует в корректном виде, ничего не поделаешь — прим. составителя)

Второй нюанс заключается в том, что скачивать исходный код из интернета при каждой сборке — идея не из лучших, и вообще-то мы ее не приветствуем. Мало ли что может случиться — ссылка перестанет работать или злоумышленник взломает сайт автора программы и подложит туда свои зловредные файлы. Поэтому официально практика скачивания исходного кода из интернета в РОСЕ запрещена, и по крайней мере в основном репозитории (main) мы за этим строго следим. Поэтому при принятии вашего запроса на изменение разработчик РОСЫ скорее всего сам скачает архив с исходным кодом и поместит его в файловое хранилище ABF. Если вы хотите избавить нас и от этой задачи, то, пожалуйста, скачайте нужные файлы самостоятельно и залейте их на http:///file-store.rosalinux.ru. После загрузки вы увидите страничку с именем загруженных файлов и их хэш-суммами:

(Картинка может быть и иной, если файл кто-то уже загружал, но хэш-сумма всё равно выводится — прим. составителя)

Имя каждого файла и его хэш-сумму, разделенные двоеточием, надо добавить в файл .abf.yml внутри проекта на ABF:

v1.3.2.zip: a23ab212c70ff02a03d1b7afb036593e36dd891a

Какие именно файлы нужно загрузить для каждого конкретного проекта — определяется его тэгами **Source **— все бинарные файлы, указанные в этих тэгах, нужно загружать на File Store.

Глава 1. Среды сборки для ОС «РОСА Linux»

1.1. Серверная среда сборки ABF ( http://abf.io )

ABF (Automatic Build Farm) — это распределенная среда разработки и сборки программных продуктов для ОС Linux и создания дистрибутивов на их основе. ABF предоставляет удобный интерфейс для одновременной сборки продукта под различные аппаратные и программные платформы.

Основные сущности ABF

ER-диаграмма ABF представлена на рисунке ниже.

• Основными действующими лицами в ABF являются пользователи, которые могут объединятся в группы.
• У каждого пользователя и каждой группы есть персональный репозиторий, в который они могут собирать свои программные проекты.
• Проект содержит исходный код приложения и другие файлы, необходимые для его сборки.
• Исходный код и текстовые файлы хранится в Git-репозитории, а бинарные файлы помещаются в отдельное файловое хранилище (а в Git-репозиторий помещается специальный файл со ссылками на бинарные файлы в хранилище).

Помимо персональных репозиториев, проекты могут быть собраны в репозитории того или иного дистрибутива, собираемого на ABF. В терминах ABF, каждому дистрибутиву Linux соответствует отдельная платформа, а репозитории платформы соответствуют репозиториям дистрибутива.

Чтобы иметь возможность собрать проект в репозиторий платформы, его необходимо явно прикрепить к этому репозиторию (что может потребовать соответствующих привилегий). Для удобства, ABF позволяет ассоциировать отдельную ветку Git-репозитория с конкретной платформой.

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

Функционал ABF

Для разработчика

• git-репозиторий;
• легковесный проектный трекер задач;
• проектная вики;
• возможность редактирования файлов в веб-интерфейсе;
• гибкое управление правами доступа к проекту, включая группы;
• проект может быть публичным, доступным для чтения всем пользователям, или приватным, доступный только ограниченному кругу лиц и невидимый остальным;
• возможность комментировать сделанные изменения (коммиты);
• возможность сравнения (diff), просмотра истории изменений (log), аннотация файла (blame) в веб-интерфейсе;
• возможность клонировать (fork) исходного кода любого публичного проекта ABF.

Для мэйтейнера

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

Для владельцев и участников платформ

• поддержка собственного дистрибутива в рамках ABF;
• возможность управление репозиториями (включение/исключение проектов);
• возможность сборки продуктов (ISO образов).

Для администраторов

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

Для всех

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

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

ABF разработан в компании РОСА полностью «с нуля» и реализован на Ruby on Rails. Работа с ABF может производиться через веб-интерфейс, через REST API, а также посредством консольного клиента.

Работа в сборочной среде ABF

(с ней Вы познакомились во введении данного руководства: «Проба пера»)

1.2. 1.2. Консольный клиент ABF

1.2.1. Теоретические сведения

--

Введение

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

В РОСЕ консольный клиент ABF входит в пакет abf-console-client и запускается из командной строки командой abf.

Первый запуск и настройки

При первом запуске, консольный клиент попросит вас задать параметры настройки и значения для некоторых опций, которые будут использоваться по умолчанию. Все эти настройки будут сохранены в файл .abfcfg в вашей домашней директории. Для изменения настроек, отредактируйте этот файл либо удалите его и запустите команду abf. Обратите внимание, что в этом файле также хранятся определения псевдонимов (см. секцию ниже), и при удалении файла они будут потеряны.

Getting Started

Типичные действия с проектами посредством консольного клиента выполняются следующим образом:

• Клонирование репозитория проекта

abf get <имя_проекта>

Имя проекта может включать его владельца (в формате <владелец>/<имя_проекта> - например, import/gcc). Если владельца не указывать, то используется значение по умолчанию из настроек клиента.

Эта команда эквивалентна вызову "git clone" со ссылкой на репозиторий проекта.

• Применить все изменения, сделанные локально в git-репозитории, и отправить их в git-репозиторий на ABF

abf put -m <сообщение>

Эта команда сначала ищет в текущей директории бинарные файлы (например, архивы с исходным кодом), которые упомянуты в spec-файле, и помещает их в файловое хранилище ABF, прописывая соответствующий файлу идентификатор в файл .abf.yml. Затем клиент определяет, какие из файлов, уже присутсвующие в .abf.yml, больше не используются в spec-файле проекта и не нужны при сборке. Такие файлы перемещаются в секцию "removed sources" файла .abf.yml; они не будут загружаться из файлового хранилища при сборке на ABF. После этих дейтсивй, "abf put" запускает последовательность команд "git add --all; git commit -m MSG; "git push".

• Запустить сборку

abf build

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

• Узнать статус сборки

abf status ID

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

• Опубликовать результаты сборки в репозиторий

abf publish ID

Если сборка завершилась успешно, то с помощью этой команды можно опубликовать собранные пакеты в целевой репозиторий дистрибутива. Заметьте, что можно попросить ABF автоматически публиковать пакет в случае успеха, указав при вызове "abf build" опцию "--auto-publish". Однако для этого автоматическая публикация должна быть разрешена настройками репозитория, а также в целевом репозитории дистрибутива не должно содержаться пакета с таким же именем, версией и релизом, как собранный.

Пример

Давайте склонируем проект import/gcc project модифицируем его (например, положим новый архив с исходным кодом и обновим spec-файл) и пересоберем пакет.

• Cклонировать репозиторий проекта и перейти в его папку

abf get import/gcc -b rosa2012.1

cd gcc

• <производим действия по модификации пакета - кладем новый архив с исходным кодом, модифицируем spec-файл и так далее>

• Загрузить новый архив с исходным кодом в файловое хранилище ABF, прописать ссылку на него в файл .abf.yml и отправить все изменения в git-репозиторий на ABF

abf put -m "Обновленная версия gcc"

• Запустить сборку обновленного проекта на ABF

abf build

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

• Узнать статус сборки

  • эта команда выведет статус последней запущенной вами сборки:

abf status

• • а также можно узнать статус сборочных заданий с заданными идентификаторами:

abf status <ID1> <ID2> ...

• Если сборка завершилась успешно, то можно опубликовать ее в репозиторий:

abf publish <ID1> <ID2> ...

Описание команд

Ниже дан список команд, официально поддерживаемых последней версией консольного клиента ABF. Вы можете запустить **abf --help *****или *abf help' для получения описаний команд, поддерживаемых вашей вресией клиента.

help

Получение детальной справки по конкретной команде (обратите внимание, что наряду с abf help <имя_команды> вы можете использовать abf <имя_команды> -h/--help)

Запуск и опции:

abf help <имя_команды>

• <имя_команды>: Имя команды, для которой необходимо вывести справку.

add

Приписать проект к репозиторию.

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

Запуск и опции:

abf add [-h] [-p <имя_проекта>] [-v] repository

• -p <имя_проекта>, --project <имя_проекта>': Имя проекта в формате <владелец>/<название>. Если имя не указано, но вы запускаете команду "abf build" из директории некоторого проекта, то к целевому репозиторию будет приписан этот проект.
• repository': Имя репозитория в формате <платформа>/<имя_репозитория> (например, rosa2012.1/main).

alias

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

Например, если вы в большинстве ваших проектов работаете в git-веткой rosa2012.1, то вам приходится их клонировать командой "abf get -b rosa2012.1" (или выполнять сначала "abf get", а потом переходить в директори склонированного проекта и выполнять там "git checkout rosa2012.1").

Однако вместо этого, вы можете определить псевдоним на сочетание опций "get -b rosa2012.1". Например, назвав этот псевдоним одной буквой "g", вы сможете просто запускать команду "abf g" и получать тот же эффект, что и при запуске "abf get -b rosa2012.1".

Заметьте, что псевдоним может замещать только часть опций и использоваться в любом месте в строке вызова. Например, можно назначить псевдоним "pack" для сочетания "rosa2012.1 build_branch -p" и запускать "abf copy pack" для копирования содержимого ветки rosa2012.1 в ветку build_branch со сжатием.

Запуск и опции:

abf alias <action> param1 [param2] [...]

• <action>: Одно из действий: list, add, remove.

add

Добавить псевдоним. Необходимо указать как минимум два аргумента - первый является именем псевдонима, а все остальные образуют его тело. Например, abf alias add sg search groups добавит псевдоним sg, который при вызове клиента будет заменяться на "search groups".

list

Вывести перечень доступных псевдонимов. По умолчанию доступны следующие псевдонимы:

b: build

sp: search projects

su: search users

st: status

s: store

spl: search platforms

sg: search groups

remove

Удалить псевдоним. В качестве аргумента необходимо передать имя псевдонима, например abf alias remove sg.

build

Запустить сборку проекта на ABF.

Обратите внимание, что несмотря на большое количество доступных опций, консольный клиент способен автоматически определять все необходимые параметры сборки при условии, что вы вызываете "abf build" из директории проекта, который хотите собрать, и активна та ветка git-репозитория, которую необходимо использовать для сборки.

Запуск и опции:

abf build [--project <имя_проекта>] [--branch <ветка> | --tag <тэг> |--commit <коммит>] [--save-to-repository <repository>] [--repository <repository>] [--arch <arch>] [--auto-publish] [--update-type <type>] [--skip-spec-check]

• -p/--project <имя_проекта>: Имя проекта в формате <владелец>/<название>. Если имя не указано, но вы запускаете команду "abf build" из директории некоторого проекта, то на будет запущена сборка этого проекта.
• -b/--branch <ветка>: ветка git-репозитория, которую надо использовать для сборки
• -t/--tag <тэг>: тэг в git-репозитории, который надо использовать для сборки
• -c/--commit <коммит>: хэш коммита в git-репозитории, который надо использовать для сборки
• -s/--save-to-repository <repository>: целевой репозиторий, для которого будет производиться сборка, в формате "<платформа>/<имя_репозитория>". Если платформа не указана, используется персональная платформа для группы по умолчанию ("<default_group>_personal"). Если эта опция не указана, но вы находитесь в git-репозитории проекта, то будет выбрана платформа, которой соответсвует текущая ветка в вашем git-репозитории, и репозиторий этой платформы, к которому этот проект привязан. Вы можете использовать команду "abf show" чтобы узнать, какие значения будут выбраны для этой опции автоматически.
• -r/--repository <repository>: репозитории, которые необходимо подключить в дополнение к целевому для сборки проекта, в формате "<платформа>/<имя_репозитория>". Эта опция может быть указана несколько раз. Если в имени репозитория опущена платформа, то выбирается целевая платформа по умолчанию ("<default_build_platform>" в файлах настроек консольного клиента ABF). Если эта опция вообще не указана, то ее значение определяется автоматически на основе сведений от ABF.
• -a/--arch <arch>: аппаратная архитектура, под которую должна производиться сборка. Опцию можно указать несколько раз. Если опция не задана, то сборка производится для архитектур i586 и x86_64.
• --auto-publish: синоним для --auto-publish-status=default
• --auto-publish-status: следует ли в случае успешной сборки автоматически публиковать собранные пакеты в целевой репозиторий. Возможные значения: 'none' (не публиковать), 'testing' (публиковать в testing-репозиторий) и 'default' (использовать настройки репозитория - если автоматическая публикация разрешена, то пакет будет опубликован).
• --skip-personal: не использовать персональный репозиторий для разрешения зависимостей.
• --testing: подключить репозиторий 'testing'.
• --no-extra-tests: не запускать дополнительные тесты.
• --auto-create-container: создавать контейнер для собранных пакетов.
• -l/--build-list: подключить контейнеры указанного сборочного задания. Опция может быть указана более одного раза.
• --cached-chroot: использовать для сборки кэшированное окружение
• --save-chroot: сохранить сборочное окружение в случае ошибки сборки
• --update-type <type>: тип обновления. Допустимые значения: security, bugfix, enhancement, recommended, newpackage. По умолчанию используется "bugfix".
• --skip-spec-check: не осуществлять проверки spec-файла и .abf.yml (см. описание команды clean).
• --skip-proj-cfg-update: не обновлять информацию о проекте в кэше проектов консольного клиента.

Выбор версии исходного кода и Git-репозитория

• Одновременно можно указать только одну из опций "--branch", "--tag" или "--commit".
• Если вы указали хэш коммита в git-репозиторий, то он будет использован "как есть" - из репозитория будет извлечен исходный код, соответсвующий этому коммиту.
• Если вы указали имя ветки или тэга, то для них с помощью ABF API будет автоматически определен хэш последнего коммита, относящегося к ветке или тэгу, и для него будет запущена сборка.
• Если вы не указали ни одной из опций "--branch", "--tag" или "--commit", не указали имени проекта с помощью опции "-p", но находитесь в директории проекта, то сборка будет запущена для последнего коммита текущего проекта, отправленного на сервер.
• Если вы указываете имя проекта с помощью опции "-p", то вам необходимо обязательно указать одну из опций "--branch", "--tag" или "--commit".

Обработка остальных опций:

• Если не указана опция --arch, то сборка производится для архитектур i586 и x86_64.
• Целевая платформа определяется на основе имени текущей ветки git-репозиотрия. Если существует платформа, имя которой совпадает с именем текущей ветки, то выбирается она. Также в клиенте есть несколько предопределенных значений (например, для проектов из группы openmandriva ветка master проассоциирована с платформой cooker).
• Целевой репозиторий определяется посредством запроса к ABF - консольный клиент запрашивает сервер, к какому репозиторию прикреплен проект на целевой платформе. Если такого репозитория нет (проект никуда не прикреплен), то клиент откажется запускать сборку и выдаст сообщение об ошибке.

Примеры:

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

abf build

• Запустить сборку проекта, отсутсвующего в локальной файловой системе, из заданной ветки. Целевой репозиторий и репозитории, которые необходимо подключить дополнительно, будут определены автоматически

abf build --project import/gcc --branch rosa2012.1

• Собрать проект под конкретную платформу; репозитории, которые необходимо подключить дополнительно, будут определены автоматически:

abf build --project import/gcc --branch rosa2012.1 --save-to-repository rosa2012lts/contrib

chain_build

Запустить цепочку сборочных заданий на ABF. Большинство опций этой команды такие же, как и у abf build. Однако в отличие от abf build, chain_build не угадывает автоматически значения различных опций, поэтому вам необходимо вручную указать все необходимые для сборки параметры (в частности, целевые репозитории и репозитории, которые необходимо подключать при сборке).

Запуск и опции:

abf chain_build [-h] [-i INFILE] [-b BRANCH] [-t TAG] [-c COMMIT] [-u TIMEOUT] [-s SAVE_TO_REPOSITORY] [-a ARCH] [-r REPOSITORY] [-l BUILD_LIST] [--auto-publish] [--auto-publish-status {default,none,testing}] [--skip-personal] [--testing] [--no-extra-tests] [--auto-create-container] [--cached-chroot] [--save-chroot] [--update-type {security,bugfix,enhancement,recommended,newpackage}] [-v] [project [project ...]]

Опции и аргументы, отличные от abf build:

• Можно указать несколько проектов, которые должны собираться поочередно. Также можно группировать проекты с использованием символа ":" (без пробелов) для обозначение проектов, которые можно собирать параллельно. Например, abf chain_build a b:c d запустит сборку проекта "a", затем (если сборка "a" завершится успешно) одновременно запустит сборки "b" и "c", а после успешного завершения сборки этих проектов запустится сборка проекта "d". Если задана опция автоматической публикации результатов сборок, то перед запуском очередного звена цепочки консольный клиент будет дожидаться публикации всех сборок предыдущего звена. Если задано автоматическое создание контейнеров, то запуск для сборок очередного звена будут подключаться контейнеры всех сборок всех предыдущих звеньев.
• -i/--infile: Файл c именами проектов. Вы можете не указывать имена проектов в командной строке, а предоставить вместо этого файл с их именами. Каждая строчка соответсвует очередному звену в цепочке сборки. Сборки проектов, указанных в одной строчке, будут запускаться параллельно. Имена проектов в строке можно отделять друг от друга двоеточием либо пробелами.
• -u/--timeout <timeout>: число секунд, которые необходимо выждать перед очередной проверкой статуса сборок.

Пример:

• Запустить цепочку сборок - сначала проекта urpmi, затем параллельно - apache и dracut, а после них - texinfo. Сборку осуществлять из ветки rosa2014.1 в репозиторий abf_personal/main, подключив репозитории rosa2014.1/main и rosa2014.1/contrib. Автоматическую публикацию отключить, но при этом включить создание контейнеров:

abf chain_build urpmi apache:dracut texinfo -b rosa2014.1 -s abf_personal/main -r rosa2014.1/main -r rosa2014.1/contrib --auto-publish-status=none --auto-create-container

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

clean

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

Отметим, что эти проверки (доступность исходных файлов и корректность spec-файлов) производятся автоматически перед запуском каджой сборки посредством "abf build". Если эти проверки находят ошибки, то консольный клиент откажется запускать сборку проекта (это поведение может быть переопределено опцией "--skip-spec-check").

В дополнение косновным проверкам, "abf clean" выводит предупреждения о файлах, которые одновременно прописаны в .abf.yml и для которых указаны Интернет-адреса в spec-файле.

Запуск и опции:

abf clean [--auto-remove]

• -a/--auto-remove: автоматически удалять все ненужные файлы.

copy

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

Запуск и опции:

• <src_branch>: Исходная ветка, из которой копируются файлы
• <dst_branch>: Целевая ветка, в которую копируются файлы. Если этот аргумент пропущен, файлы копируются в текущую ветку
• -p/--pack: Создать архив в формате tar.gz из файлов исходной ветки и скопировать в целевую ветку этот архив, а не сами файлы

create

Создать проект из файла SRPM.

Запуск и опции:

abf create [-h] [-b BRANCH] [--no-def-branch] [-v] srpm [owner]

• srpm: файл srpm
• owner: кто будет владельцем проекта; по умолчанию используется значение default_owner
• -b BRANCH, --branch BRANCH: создать дополнительную ветку; параметр может быть указан несколько раз
• --no-def-branch: не создавать автоматически ветку, указанную как ветка по умолчанию в конфигурационном файле (только если эта ветка отлична от "master").

destroy

Удалить проект. Будьте осторожны - удаленный проект восстановить нельзя!

Запуск и опции:

abf destroy [-h] [-v] project

• project: Имя проекта в формате <владелец>/<название>. Если владелец не указан, используется значение по умолчанию.

fetch

Загрузить все файлы, указанные в основной секции файла .abf.yml, в текущую директорию. Файлы, указанные в секции "removed_sources", не загружаются.

Запуск и опции:

abf fetch [--only <file_name>]

• -o/--only <file_name>: Limit the list of downloaded files to this file name(s). This option can be specified more than once.

fork

Склонировать проект

Запуск и опции:

abf fork [-h] [-v] source_project [target_project]

• source_project: имя проекта для клонирования в формате <владелец>/<название> (например, import/gcc)
• target_project: имя нового проекта в формате <владелец>/<название> (например, mygroup/mygcc). Если этот параметр не указать, то исходный проект будет склонирован в проект с таким же именем в группу, указанную как группа по умолчанию в настройках консольного клиента.

get

Склонировать удаленный git-репозиторий по его владельцу и имени на локальную машину. Например, abf get import/gcc склонирует проект gcc из группы import. Проект будет склонирован в текущую директорию. Если в директории уже есть поддиректория, чье имя совпадает с именем проекта, консольный клиент откажется выполнять клонирование и выдаст соответсвующее предупреждение.

Запуск и опции:

abf get <имя_проекта> [--branch <имя_ветки>]

• <имя_проекта>: имя проекта для клонирования в формате <владелец>/<название> (например, import/gcc). Если имя владельца не указывать, то используется значение по умолчанию из настроек консольного клиента.
• -b/--branch <имя_ветки>: имя ветки git-репозитория, которая будет автоматически сделана активной после клонирования (то есть после клонирования abf дополнительно вызовет команду "git checkout <имя_ветки> внутри директории проекта").
• --skip-proj-cfg-update: не обновлять информацию о проекте в кэше проектов консольного клиента.

info

Получить информацию об одной из сущностей - платформе, репозитории или проекте.

Запуск и опции:

abf info {platforms,repositories,projects} [-f [FILTER [FILTER ...]]] [-o [OUTPUT [OUTPUT ...]]]

• -f [FILTER [FILTER ...]], --filter [FILTER [FILTER ...]]: Можно задать фильтр, указав набор пар вид.атрибут=значение или атрибут=значение, где вид - одно из значений: ['platforms', 'repositories', 'projects'], атрибут - один из атрибутов сущности данного вида либо специальный атрибут ('page' - используется для вывода заданных страниц поиска), а значение - строка, в роли которой можно указать символ '*' для вывода всех значений.
• -o [OUTPUT [OUTPUT ...]], --output [OUTPUT [OUTPUT ...]]: формат вывода

Пример

• Получить имена всех проектов в платформе rosa2012lts: abf info projects -f platforms.name=rosa2012lts page=*

locate

Управление базой данных о локальных репозиториях.

Консольный клиент поддерживает локальную базу данных (в виде текстового файла .abf_projects в вашей домашней директории), в которой содержатся пути (в локальной файловой системе) к репозиториям, которые вы клонировали с помощью клиента abf, и идентификатор последнего сборочного задания, относящегося к этому проекту. Эта база используется командой abfcd для быстрого перехода в директории проектов (см. раздел "Дополнительные возможности").

"abf locate" может быть использована для просмотра и изменения информации о локальных репозиториях проектов.

Запуск и опции:

abf locate [<action>] [--project <имя_проекта>] [--directory <директория>]

• <action>: одно из действий "update" или "update-recursive". Эти действия заставляют abf просканировать директорию, указанную с помощью опции "-d", на предмет наличия в них клонированных проектов, и добавить найденные проекты в базу данных. update добавит проект только в случае, если указанная директория и является директорией с клонированным проектом. "update-recursive" рекурсивно просканирует все директории в указанной и добавит в базу данных все найденные там проекты. Если действие не указано, то команда выведет путь к локальному репозиторию для заданного проекта
• -p/--project <имя_проекта>: имя проекта, о котором надо вывести информацию, в формате <владелец>/<имя>. Если владелец не задан, используется значение по умолчанию из настроек клиента.
• -d/--directory <директория>: директория, которая будет просканирована на предмет наличия в ней проектов, при указании действий "update" или "update-recursive".

mock-urpm

Собрать проект локально с использованием mock-urpm. Для сборки используется текущее состояние локального репозитория.

Запуск и опции:

abf mock-urpm [-c <config>]

• -c/--config <config>: A config template to use. Specify one of the config names from /etc/abf/mock-urpm/configs/. Directory path and extension (".cfg") should be omitted. If no config specified, "default.cfg" will be used. Autocompletion worsk for config names.

Замечание:

• Перед сборкой пакета вызывается "abf fetch". При этом если вы в текущей директории модифицировали какой-то файл, который прописан в .abf.yml, то ваш файл будет перезаписан версией из файлового хранилища.
• Сборка с помощью mock-urpm производится в директории /var/lib/abf/mock-urpm.

proj_alias

Создать ссылку (алиас) длясуществующего проекта. Адиасы являются различными проекатми с точки зрения ABF, но используют один и тот же Git-репозиторий.

Запуск и опции:

abf proj_alias [-h] [-v] source_project target_project

• source_project: имя исходного проекта в формате <владелец>/<название>.
• target_project: имя нового проекта в формате <владелец>/<название>.

publish

Опубликовать успешно завершенное сборочное задание.

Запуск и опции:

abf publish <task_id> [<task_id>] [...]

• <task_id>: идентификатор сборочного задания

pullrequest

Отправить запрос на перенос изменений ("pull request") из ветки или метки SRC_BRANCH git-репозитория проекта в ветку DST_BRANCH этого же проекта.

Запуск и опции:

abf pullrequest [-h] [-p PROJECT] [-v] from_ref to_ref title body

• <from_ref>: ветка-источник
• <to_ref>: целевая ветка
• <title>: название запроса
• <body>: комментарий к запросу
• -p <имя_проекта>, --project <имя_проекта>: имя проекта в формате "владелец/название" (например, "import/gcc"). По умолчанию используется проект, в директории которого выполняется команда

put

Загрузить изменения в проекте, сделанные локально, на сервер ABF.

Первым шагом комагда "abf put" загружает бинарные файлы из текущей директории на файловый сервер ABF и добавляет их идентификаторы в файл .abf.yml. После этого определяются файлы, указанные в .abf.yml, которые больше не нужны для сборки (не упоминаются в spec-файле проекта). Такие файлы перемещаются в секцию removed_sources файла .abf.yml; они не будут извлекаться при сборке проекта на ABF. после этого все изменения в проекте, сделанные локально применяются и отправляются в удаленный git-репозиторий (аналогично командам "git add --all", "git commit" и "git push"). По умолчанию бинарные файлы, загруженные на файловый сервер ABF, из текущей директории удаляются.

Запуск и опции:

abf put [-m|--message <сообщение>] [--minimal-file-size <size>] [--do-not-remove-files]

• -m, --message <сообщение>: если этот параметр задан, то консольный клиент закоммитит все изменения в git и сделает "git push", а указанное сообщение будет использовано как комментарий к изменениям (передается команде "git commit")
• -s, --minimal-file-size <size>: минимальный размер бинарного файла, при превышении которого файл загружается на файловый сервер. По умолчанию используется 0, то есть на файловый сервер загружаются все бинарные файлы.
• -n, --do-not-remove-files: Не удалять бинарные файлы из текущей директории после их загрузки на файловый сервер ABF.
• -a, --upload-all: По умолчанию, консольный клиент анализирует spec-файл и загружает в файловое хранилище только те файлы, которые в нем используются. Если указать эту опцию, то в файловое хранилище будут загружены все бинарные файлы из текущей директории.

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

remote

Добавить удаленный Git-репозиторий и извлечь его содержимое.

Запуск и опции:

abf remote [-h] [-v] remote_group [remote_name]

• remote_group: Группа ABF, которой принадлежит удаленный репозиторий. Это же имя будет использовано как имя репозитория.
• remote_name: Имя удаленного проекта. По умолчанию используется такое же имя, как у текущего проекта.

Пример:

• Извлечем проект foo группы openmandriva:

abf get openmandriva/foo

• Добавим удаленный репозиторий проекта с таким же именем из группы import:

abf remote import

• Теперь у нас подключен удаленный репозиторий с названием "import" - это репозиторий проекта import/foo.Мы можем, например, слить изменения из одной из его веток в нашу текущую ветку:

git merge import/rosa2014.1

remove

Удалить привязку проекта к репозиторию.

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

Запуск и опции:

abf remove [-h] [-p <имя_проекта>] [-v] repository

• -p <имя_проекта>, --project <имя_проекта>': Имя проекта в формате <владелец>/<название>. Если имя не указано, но вы запускаете команду "abf build" из директории некоторого проекта, то будет удалена связь для этого проекта.
• repository': Имя репозитория в формате <платформа>/<имя_репозитория> (например, rosa2012.1/main).

rpmbuild

Собрать проект локально с использованием rpmbuild. Для сборки используется текущее состояние локального репозитория.

Запуск и опции:

abf rpmbuild [-h] [-b {b,s,a}] [-v]

• -b {b,s,a}, --build {b,s,a} - собрать SRPM-пакет (s), бинарный RPM-пакет (b) или оба (a)

search

Поиск по ABF.

Запуск и опции:

abf search <target> "<query>"

• <target>: область поиска; допустимые значения:

  • users - пользователи
  • groups - группы
  • platforms - платформы
  • projects - проекты

• <query>: Строка для поиска. Регулярные выражения и шаблоны не поддерживаются.

show

Показать детальные сведения о проекте. Эта команда используется для автодополнения в оболочке Bash.

Запуск и опции:

abf show <target> [--project <имя_проекта>]

• <target>: Какую именно информацию показывать. Доступные варианты:

  • build-repos - репозитории, которые можно подключать при сборке проекта
  • build-platforms - платформы, репозитории которых можно подключать при сборке проекта
  • save-to-repos - репозитории, в которые можно публиковать результаты сборки проекта (пакеты)
  • save-to-platforms - платформы, в репозитории которых можно публиковать результаты сборки проекта (пакеты)

• -p/--project <имя_проекта>: Имя проекта, о котором необходимо показать информацию. Если вы находитесь внутри git-репозитория проекта, то можно эту опцию не указывать, в этом случае будут выведены данные о текущем проекте.

Замечание: в имя репозитория всегда включается имя платформы, к которой он относится - например, "rosa2012.1/main" соответствует репозиторию "main" платформы "rosa2012.1".

status

Показать информацию о сборочном задании. Выводит сведения в следующем виде:

Buildlist ID: 944492

User: akirilenko

Project: import/mock-urpm

Status: build has been published

Build for platform: rosa2012.1

Save to repository: rosa2012.1/main

Build repositories: [rosa2012.1/main]

Architecture: i586

Created at: 2013-02-12 15:25:09

Updated at: 2013-02-12 15:43:16

Запуск и опции:

abf status [--project <имя_проекта>] [--short]

• -p/--project <имя_проекта>: Если не указан идентификатор сборочного задания, но указано имя проекта с помощью этой опции, то консольный клиент извлечет идентификатор последнего запущенного сборочного задания для этого проекта из локальной базы данных (если такое хначение там есть) и отобразит его статус.
• -s, --short: показать информацию в сжатом виде (одна строка - идентификатор сборки, имя проекта, архитектура и статус).

store

Загрузить заданный файл на файловое хранилище ABF. В случае успеха, клиент напечатает идентификатор файла (sha1-сумму).

Если файл с такой же хэш-суммой уже присутствует в файловом хранилище, но он не будет перезаписан.

Запуск и опции:

abf store <path>

• <path>: Путь к файлу для загрузки.

test

Запустить набор внутренних тестов.

Эта команда может быть использована для проверки исправности консольного клиента и окружения. В штатном режиме работы, тесты не должны выявлять никаких проблем и должны печатать результирующую фразу "Datamodel seems to work fine".

update

Изменить настройки проекта.

Запуск и опции:

abf update [-h] [-p PROJECT] [--name [NAME]] [--desc [DESC]] [--visibility {open,hidden}] [--is_pkg {true,false}] [--branch [BRANCH]] [--issues {true,false}] [--wiki {true,false}] [--biarch {true,false}] [-v]

• -p PROJECT, --project PROJECT проект, для которого необходимо показать информацию. Формат: "[группа/]имя". Если группа не указана, используется значение по умолчанию из настроек.
• --name [NAME]: Новое имя проекта.
• --desc [DESC]: Версия проекта.
• --visibility {open,hidden}: Видимость (доступность) проекта. Укажите "open" или "hidden".
• --is_pkg {true,false}: Является ли проект пакетом. Укажите "true" или "false".
• --maintainer [ID_OR_USERNAME]: Мэйнтйенер проекта. Можно указать имя пользователя либо его идентификатор в ABF.
• --branch [BRANCH]: Ветка по умолчанию для Git-репозитория проекта.
• --issues {true,false}: Следует ли включить трекер задач для проекта. Укажите "true" или "false".
• --wiki {true,false}: Следует ли включить вики для проекта. Укажите "true" или "false".
• --biarch {true,false}: Включить публикацию 32битных пакетов в 64битный репозиторий. Укажите "true" или "false".

Дополнительные возможности

Кэш локального местоположения проектов

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

abfcd <имя_проекта>

Эта информация хранится в файле .abf_projects в вашей домашней директории.

Узнать местоположение проекта в вашей файловой системе можно с помощью следующей команды:

abf locate -p <имя_проекта>

Если у вас есть набор репозиториев, отсутствующих в кэше консольного клиента (например, если они были склонированы непосредственно с помощью команды git, или если вы удалили файл .abf_projects), вы можете заставить консольного клиента просканировать заданную директорию и поместить в кэш все проекты, которые он там найдет:

abf locate update-recursive -d <путь_к_директории_с_проектами>

Помимо команды "abfcd", информация из файла .abf_projects используется при перемещении файлов между различными проектами с помощью консольного клиента ABF.

Обновление кэша занимает некоторое время, и если вы обрабатываете большое количество пакетов, то имеет смысл его отключить. Это можно сделать, указав опцию --skip-proj-cfg-update (поддерживается командами get, build и chain_build).

Автодополнение в Bash

Консольный клиент ABF предоставляет богатые возможности по автоматическому дополнению команд и опций при использовании в оболочке Bash. В частности, он способен предлагать варианты дополнения для имен опций, веток git, целевых репозиториев для сборки (параметров build и save-to команды "abf build") и множества других команд. Это существенно облегчает работу с клиентом, поскольку отпадает необходимость в ручном вводе длинных имен и запоминании большого количества опций. В некоторых случаях автоматическое дополнение может работать более 1 секунды, однако все результаты обращения к автоматическому дополнению кэшируются и последующие вызовы проходят гораздо быстрее.

---

---

1.2.2. Практический пример работы с abf-console-client

Как создать установочный rpm-файл на примере попытки повышения версии p7zip с 15.14.1 до 16.02.

Предварительное замечание:

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

0.1. Идём на https://abf.io/users/sign_up и регистрируемся.

1.1 Nickname - ваш ник латиницей. Пример: survolog

1.2 User - ФИО латиницей. Пример: Grigorev Andrey Alexandrovich

1.3 Email - Почта. Пример: survolog@yandex.ru

1.4 Password - пароль. Пример: parolparol

1.5 Confirmation - повтор пароля 1.4. Пример: parolparol

1.6 Sign_up - регистрация. Нажимаем.

1.7 Идём в свою почту и ждём письма от Rosa Build no-reply@npp-build.rosalab.ru. Нажимаем в письме по ссылке Confirm my account.

2. Идём на https://abf.io/users/sign_in

2.1 Nickname - набираем 1.1. Пример: survolog

2.2 Password - набираем 1.4. Пример: parolparol

2.3 Remember me - запомнить ник с паролем. Ставим галочку.

2.4 Sign_in - вход. Нажимаем.

2.5 Справа сверху кликаем по шестерёнке и выбираем Settings.

2.6 В поле Language выбираем Russian.

2.7 Save - сохранение. Нажимаем.

3 Идём на https://abf.io/import

3.1 Вводим название проекта. Пример: 7zip.

3.2 Нажимаем — Искать.

3.3 Кликаем по найденному p7zip.

3.4 Справа сверху: Текущая ветка/тег: выбираем rosa2016.1

3.5 Нажимаем Клонировать.

3.6 Нажимаем Клонировать в survolog/p7zip

3.7 Обновляем страничку на F5 (в браузере FF, ещё вариант Ctrl+r).

3.8 Повторяем Справа сверху: Текущая ветка/тег: выбираем rosa2016.1

4. Открываем консоль.

4.1 urpmi abf-console-client

4.2 abf

4.2.1 Ответ:

Схема файла конфигурации была изменена либо файл поврежден, перезапускаем настройку конфигурации

ABF URL [https://abf.rosalinux.ru\]:

4.2.2 Нажимаем Enter.

Ответ:

User [survolog]:

4.2.3 Набираем Nickname из 1.1 и нажимаем Enter.

Ответ:

Password:

4.2.4 Набираем пароль из 1.4 и нажимаем Enter.

Ответ:

Default project branch [master]:

4.2.5 Набираем rosa2016.1 и нажимаем Enter.

Ответ:

Default project owner [Survolog]:

4.2.6 Набираем Nickname из 1.1 и нажимаем Enter.

Ответ:

Default platform [rosa2014.1]:

4.2.7 Набираем rosa2016.1 и нажимаем Enter.

Ответ:

File-store URL [http://file-store.rosalinux.ru\]:

4.2.8 Нажимаем Enter.

Ответ:

Default publishing status for new builds [default]:

4.2.9 Нажимаем Enter.

Ответ:

Конфигурация успешно завершена

Теперь вы можете запустить "abf locate update-recursive -d PATH", где PATH - это ваша директория с клонированными проектами ABF. Это позволит вам использовать команду "abfcd <project>" для перехода в директорию проекта.

usage: abf [-h] [-v] [-c] [-q]

{help,alias,get,put,store,update,fetch,remote,show,locate,build,chain_build,mock-urpm,rpmbuild,publish,copy,pullrequest,fork,proj_alias,create_empty,create,destroy,add,remove,status,clean,search,info,test}

...

abf: error: too few arguments

4.2.10 Если что-то ввели неправильно (например, Survolog вместо survolog), то rm .abfcfg и снова на 4.2.

===================================================================

4.3 abf get -b rosa2016.1 p7zip

Ответ:

Клонирование в «p7zip»…

4.4 cd p7zip

4.5 ls -a

Ответ:

./ ../ 07_natspec.patch .abf.yml CVE-2016-2334.patch CVE-2016-2335.patch .git/ p7zip.spec

4.6 kwrite p7zip.spec - открываем спек от p7zip. kwrite - текстовый редактор. Можно использовать и другой. Например, vim.

4.6.1 В Version: меняем 15.14.1 на 16.02

4.6.2 В Release: меняем 4 на 0

4.6.3 В Source0: меняем 15.09 на 16.02

4.6.4 Стираем строки Patch0, Patch1 и Patch2

4.6.5 Стираем строку %apply_patches

4.6.6 Сохраняем изменения спека.

4.7 urpmi ./p7zip.spec

Ответ:

умолчания для --buildrequires

==> warning: tag 1044 type(0x0) != implicit type(0x10006)

4.8 abf rpmbuild

Ответ - длинный процесс,оканчивающийся на:

1 packages and 0 specfiles checked; 0 errors, 4 warnings.

Записан: /tmp/abf/rpmbuild/RPMS/x86_64/p7zip-16.02-0-rosa2014.1.x86_64.rpm

Executing "/usr/bin/rpmlint -T -f /tmp/abf/rpmbuild/p7zip.rpmlintrc /tmp/abf/rpmbuild/RPMS/x86_64/p7zip-16.02-0-rosa2014.1.x86_64.rpm":

1 packages and 0 specfiles checked; 0 errors, 0 warnings.

Перемещаем файлы в текущую директорию...

SRPM: /home/survolog/p7zip/p7zip-16.02-0.src.rpm

RPM: /home/survolog/p7zip/p7zip-16.02-0-rosa2014.1.x86_64.rpm

4.9 ls -a

Ответ содержит два rpm-файла, программа в p7zip-16.02-0-rosa2014.1.x86_64.rpm:

./ .abf.yml .git/ p7zip-16.02-0.src.rpm

../ CVE-2016-2334.patch p7zip_15.14.1_src_all.tar.bz2 p7zip.spec

07_natspec.patch CVE-2016-2335.patch p7zip-16.02-0-rosa2014.1.x86_64.rpm

Спасибо за внимание!

Как отправить созданный установочный файл rpm в собственный репозиторий на примере p7zip версии 16.02.

Предварительное замечание:

Это продолжение к тексту "Про создание rpm.txt" (Как создать установочный файл rpm на примере попытки повышения версии p7zip с 15.14.1 до 16.02). Подразумевается, что тестирование на работоспособность проведено.

1. abf put -m "update to 16.02 and warning delete all patches on 15.14.1" - при тестировании программы проблем пока не нашёл, но патчи я из неё удалил и подумал, что важно упомянуть это.

Ответ:

Файл p7zip_16.02_src_all.tar.bz2 не найден, при сборке будет использоваться ссылка. Пропускаем.

*** Please tell me who you are.

Run

git config --global user.email "you@example.com"

git config --global user.name "Your Name"

to set your account's default identity.

Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'survolog@survolog-desktop.(none)')

1.1 git config --global user.email "survolog@yandex.ru" - вносим свою почту.

1.2 git config --global user.email "survolog" - вносим свой никнейм.

2. abf put -m "update to 16.02 and warning delete all patches on 15.14.1"

Ответ оканчивается на:

Изменения отправлены на сервер.

3. Идём на https://abf.io/survolog/p7zip/tree/rosa2014.1

3.1 Смотрим на p7zip.spec. Дата публикации должна быть свежей.

4. Нажимаем "Новая сборка".

4.1 Собрано для платформы rosa2016.1 main галочка.

4.2 Версия rosa2016.1

4.3 Архитектура i586 галочка и x86_64 галочка

4.4 Критичность обновления enhancement

4.5 Создать контейнер автоматически — галочка (может и не надо — прим. составителя)

4.6 Использовать дополнительные тесты - галочка (может и не надо — -»-)

4.7 Нажимаем "Начать сборку"

5. Нажимаем птичку под id и видим две сборки - под i586 и под x86_64.

5.1 Ждём, пока статус обеих не остановится на "Опубликован".

6. Слева сверху нажимаем "Платформы".

6.1 Нажимаем название survolog_personal

6.2 Целевая платформа - rosa2016.1

6.3 Целевая архитектура - x86-64

6.4 Копируем и вставляем в терминал полученную ниже команду:

urpmi.addmedia survolog_personal http://abf-downloads.rosalinux.ru/survolog\_personal/repository/rosa2014.1/x86\_64/main/release

6.5 Добавляем в начало команды sudo и отправляем:

sudo urpmi.addmedia survolog_personal http://abf-downloads.rosalinux.ru/survolog\_personal/repository/rosa2014.1/x86\_64/main/release

7. Ставим собранную нами программу:

urpmi p7zip

Ответ:

http://abf-downloads.rosalinux.ru/survolog\_personal/repository/rosa2014.1/x86\_64/main/release/p7zip-16.02-0-rosa2014.1.x86\_64.rpm

устанавливается p7zip-16.02-0-rosa2014.1.x86_64.rpm из /var/cache/urpmi/rpms

Подготовка... ################################################################################

1/1: p7zip ################################################################################

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

9. Повторяем пункты 6-8 для архитектуры i586 на подходящем компьютере.

Спасибо за внимание!

Про правку .abf.yml

Есть такой скрытый файлик .abf.yml

Нужен он для скачивания исходников, хранящихся на abf.io, точнее, на

http://file-store.rosalinux.ru/

куда эти исходники предварительно надо залить (Add files, Start upload), для чего в процессе набрать логин с паролем от вашего профиля на abf.io.

После этого сайт выдаст ключ типа "ae2e7a6240efade7ea3dcdf3ebd74a34fcf3805a", который и надо использовать в .abf.yml.

Про diff.

Команда diff нужна для создания патчей к коду.

Распаковывается код (тарбол), копируется, сравнивается при помощи diff со своим пропатченным вручную вариантом в файл. Полученный файл можно использовать в качестве патча (*.patch).

Пример использования команды:

diff -ur p7zip_16.02 p7zip_16.02_patched > p7zip_16.02.patch

1.3. Сборка-обновление в mock-urpm

1.3.1. Сборка через mock-urpm на примере featherpad-0.6.

1. sudo urpmi mock-urpm

2. Создаём в Домашней папке - каталог mock-urpm, и в нём три подкаталога

• SPECS, SOURCES и SRPMS.

(удобнее создать каталог ~/mock-urpm, в нём каталог для нужного проекта, а там уже нужные рабочие каталоги — прим. составителя)

mkdir -p ~/mock-urpm/{SOURCES,SPECS,SRPMS}

3. Помещаем в SPECS - featherpad.spec, а в SOURCES - FeatherPad-0.6.tar.gz.

4. Команда.

mock-urpm -v --buildsrpm --spec='/home/ИМЯ_ПОЛЬЗОВАТЕЛЯ/mock-urpm/SPECS/featherpad.spec' --sources='/home/ИМЯ_ПОЛЬЗОВАТЕЛЯ/mock-urpm/SOURCES/FeatherPad-0.6.tar.gz'

(удобно при этом перетаскивать файлы и каталоги в окно консоли мышкой и, при необходимости, заключать полученные адреса в 'кавычки' — прим. составителя)\

mock-urpm -v --buildsrpm --spec='/home/vladimir/mock-urpm/SPECS/*.spec' --sources='/home/vladimir/mock-urpm/SOURCES/

(Если в папке SOURCES помимо архива программы есть ещё доп. файлы то команда оканчивается просто наименованием папки SOURCES)

mock-urpm -v --buildsrpm --spec='/home/ИМЯ_ПОЛЬЗОВАТЕЛЯ/mock-urpm/SPECS/featherpad.spec' --sources='/home/ИМЯ_ПОЛЬЗОВАТЕЛЯ/mock-urpm/SOURCES/

4.1 Ответ:

Mandriva-2011-i586, Mandriva-2011-x86_64, Mandriva-cooker-i586, Mandriva-cooker-x86_64, Rosa-2012.1-i586, Rosa-2012.1-x86_64, Rosa-2012lts-i586, Rosa-2012lts-x86_64, Rosa-2014.1-i586, Rosa-2014.1-x86_64, Rosa-2016.1-i586, Rosa-2016.1-x86_64

Select one (it will be remembered):

Вводим: Rosa-2016.1-x86_64

4.2 Пошла загрузка пакетов для создания сборочной среды.

4.3 Вырезка из вывода:

DEBUG: Платформы для сборки: x86_64

DEBUG: Записан: /builddir/build/SRPMS/featherpad-0.6-1.src.rpm

DEBUG: Executing "/usr/bin/rpmlint -T -f /builddir/build/SOURCES/featherpad.rpmlintrc /builddir/build/SRPMS/featherpad-0.6-1.src.rpm":

DEBUG: 1 packages and 0 specfiles checked; 0 errors, 0 warnings

...

INFO: Done(featherpad.spec) Config(default) 5 minutes 28 seconds

INFO: Results and/or logs in: /var/lib/mock-urpm/Rosa-2016.1-x86_64/result

5. Копируем полученный featherpad-0.6-1.src.rpm из /var/lib/mock-urpm/Rosa-2016.1-x86_64/result в каталог SRPMS

6. Команда.

mock-urpm -v --no-clean '/home/ИМЯ_ПОЛЬЗОВАТЕЛЯ/mock-urpm/SRPMS/featherpad-0.6-1.src.rpm'

6.1 Пошла сборка.

6.2 Вырезка из вывода:

DEBUG: Wrote: /builddir/build/RPMS/featherpad-0.6-1-rosa2016.1.x86_64.rpm

DEBUG: Wrote: /builddir/build/RPMS/featherpad-debuginfo-0.6-1-rosa2016.1.x86_64.rpm

DEBUG: Executing "/usr/bin/rpmlint -T -f /builddir/build/SOURCES/featherpad.rpmlintrc /builddir/build/RPMS/featherpad-0.6-1-rosa2016.1.x86_64.rpm /builddir/build/RPMS/featherpad-debuginfo-0.6-1-rosa2016.1.x86_64.rpm":

DEBUG: featherpad.x86_64: W: no-documentation

DEBUG: 2 packages and 0 specfiles checked; 0 errors, 1 warnings.

...

INFO: Done(/home/survolog/mock-urpm/SRPMS/featherpad-0.6-1.src.rpm) Config(default) 1 minutes 38 seconds

INFO: Results and/or logs in: /var/lib/mock-urpm/Rosa-2016.1-x86_64/result

6.3 Собранные rpm лежат по адресу:

/var/lib/mock-urpm/Rosa-2016.1-x86_64/result

(и их лучше переместить до начала следующей сборки, иначе они будут стёрты — прим. составителя)

(папку «result» можно добавить в «Точки входа» в Dolphin или (в консоли) добавить переход туда алиасом)

(то же самое актуально и для Nautilus — прим. составителя)

**1.4. Сборка-обновление в rpmbuilld **

1.4.1. Сборка RPM - быстрый старт

--

** Подготовка к сборке и обзор spec-файла**

Сперва давайте разберёмся, что должно быть в системе для сборки rpm-пакета. Обязательно должен быть установлен пакет rpm-build. Без него не будет доступна команда rpmbuild. Наряду с ним, по зависимостям поставится еще ряд пакетов, используемых при сборке. В зависимостях для сборки пакета в РОСЕ обычно не принято прописывать компилятор C/C++, по этому поводу рано или поздно вам понадобятся пакеты gcc и gcc-c++ Все остальные зависимости должен попросить сам пакет. Конечно бывают промахи, и в процессе сборки вы понимаете, что что-то упустили, но это обычно бывает довольно редко и не критично.

А что собственно из себя представляет RPM пакет? RPM-пакеты делятся на пакеты с исходниками - src.rpm и пакеты, готовые к установке - %{arch}.rpm. В src.rpm пакетах содержится исходный тарболл (исходник программы), какие-либо другие исходники, пачти и самый главный spec-файл, который управляет процессом сборки. Все эти файлы упакованы в cpio архив. Когда вы пытаетесь войти в src.rpm пакет при помощи файлового менеджера mc, вы его увидите. Также в пакете присутствует некоторые файлы с информацией.

В %{arch}.rpm-пакетах содержится cpio-архив с файлами, которые после установки разложатся по соответствующим каталогам, файлы информации и установочные скрипты.

Также вы можете встретить без исходного кода. Обычно их создают для проприетарных программ, которые нельзя включать в дистрибутив (исходников нет, а бинарник каким-то образом нужно переделать либо просто запрещено размещать на зеркалах дистрибутива лицензией). Внутри этого пакета находится обычно только spec-файл, а бинарник скачивается и, при необходимости, модифицируется, в процессе установки пакета (например, в post-скрипте, о котором речь пойдет ниже).

Собирать пакеты можно из-под любого пользователя. Делать это из-под root'а не рекомендуется, т.к. есть вероятность, что корнем для секции инсталляции окажется каталог / и тогда команда rm -rf %{buildroot} уничтожит все на свете. Также бывает, что «кривые» пакеты не правильно выполняют инсталляцию, и ставятся не во временный каталог, а прямо куда-нибудь в ***%{_prefix} ***(/usr). Часть файлов будет потеряна, хотя на работоспособности пакета на этой машине понятное дело это не скажется.

Что нужно сделать, чтобы можно было собирать пакеты из-под обычного пользователя? Первым делом нужно создать в своём домашнем каталоге файл директорию rpmbuild со следующей структурой:

~/rpmbuild

|-- BUILD

|-- BUILDROOT

|-- RPMS

| |-- i586

| |-- x86_64

| `-- noarch

|-- SOURCES

|-- SPECS

`-- SRPMS

Каталоги BUILD, RPMS, SOURCES, SPECS, SRPMS вам необходимо создать вручную, подкаталоги каталога RPMS должны создаться автоматически во время сборки в зависимости от архитектуры.

mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}

В РОСЕ не принято писать сборщика пакета и вендора в spec-файлах; эти значения выставляются автоматически системой сборки ABF. Также ABF автоматически подписывает собранные пакеты ключом соответствующего репозитория. Поэтому эти вопросы мы здесь затрагивать не будем.

** Сборка пакетов для 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-пакета, spec-файл. Для примера возьмём его из пакета stardict. Этот пакет хорошо подходит для обучения, так как в нем есть несколько тарболов (исходник программы, упакованный tar’ом), получается несколько пакетов и есть такая вещь, как схемы. Обычно spec-файл имеет такое же имя, как и сам пакет (stardict.spec). Однако вы можете добавить версию пакета (stardict-2.spec), удобно если вы пытаетесь поддерживать несколько веток программ. Можно даже дать какое-нибудь другое название, однако это мягко говоря не удобно.

Итак, содержимое файла stardict.spec приведено ниже. Мы сразу будем вставлять комментарии после определенных секций, но если вы соедините все блоки в один и тот же файл, то получите полноценный stardict.spec.

Spec-файл состоит из секций и шапки:

Summary: StarDict dictionary

Name: stardict

Version: 2.4.8

Release: 4

License: GPL

URL: http://stardict.sourceforge.net

Group: User Interface/Desktops

Source0: %{name}-%{version}.tar.bz2

Source1: %{name}-tools-%{version}.tar.bz2

Patch0: %{name}-2.4.8-desktop.patch

Summary — краткое описание пакета, Name — название, Version — версия, Release — релиз. Последним трем тегам соответствуют макроопределения ***%{name} ***, ***%{version} ***, ***%{release} ***. Их часто используют в дальнейшем. Name и Version обычно совпадает с название тарбола. Если же они отличаются, то в принципе ничего страшного, но придётся в некоторых местах spec-файла действовать нестандартными методами. Если вы собираете пакет из cvs, svn и т. д., то рекомендуется в самом начале файла сделать макроопределение %define date 20070422 (именно в таком формате, сами догадайтесь почему) и тег Release определить следующим образом:

Release: 0.git%{date}.4

Далее, License — лицензия, под которой распространяется программа (обычно указано в самом пакете). Раньше в ходу был также тег Copyright, но сейчас он не используется. URL — сайт программы, Group — группа, в которую будет входить данный пакет. Обычно следует прикинуть на что этот пакет похож, и посмотреть группу похожего пакета. Придумывать группу самому не стоит, лучше посмотреть в список имеющихся.

Source* — исходные тексты, тарболы, просто файлы. В данном примере идут два тарбола с разными программами, что делает сборку намного сложнее. Обычные файлы, например, конфигурации, могут просто копироваться в секции %%install при помощи команды install. У нее простой синтаксис, install -m маска_как_у_chmod что куда. При помощи нее можно также создавать каталоги. В нашем примере она не используется, но подробнее про неё можно почитать в man.

Patch — патчи, исправления, которые вы или кто-то другой выпустили для данного пакета. Не принято изменять исходный текст самой программы, а затем завертывать ее в тарбол. Принято накладывать заплатки. Делать их можно следующим образом. Распаковываете исходный тарбол, у нас это будет stardict-2.4.8, далее копируете stardict-2.4.8 в stardict-2.4.8.orig. После этого изменяете код в каталоге stardict-2.4.8, выходите из него и отдаете команду diff -ur stardict-2.4.8.orig stardict-2.4.8 > stardict-2.4.8-название_патча.patch. Как видно, до навания патча идёт %{name}-%{version} пакета. В самом spec-файле обязательно следует писать название патча без макроопределений. По крайней мере версию, точно. Иначе при обновлении версии пакета, у вас и обновится версия патча, определённая макросом ***%{version} ***, а патч может быть подойдёт к новой версии программы и без каких либо изменений. Если же во время самой сборки патч не смог наложиться, то его следует либо переделать под данную версию программы, либо отключить в секции ***%setup ***.

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

BuildRequires: libgnomeui-devel >= 2.2.0

BuildRequires: scrollkeeper

BuildRequires: gettext

Requires(post): GConf2

Requires(post): scrollkeeper

Requires(postun): scrollkeeper

BuildRequires — секция, в которую через запятую или через пробел прописываются пакеты, которые требуются для сборки нашей программы. Почерпнуть их можно из каких-нибудь файлов README и INSTALL (хотя там редко бывает что-то полезное по этому поводу), из процесса конфигурации (на данный момент обычно это скрипт configure) и из самого процесса сборки (иногда configure что-нибудь пропустит и сборка остановится).

Requires — в эту секцию записываются пакеты или файлы(!), которые будет требовать данный пакет при установке. При сборке в зависимости автоматически пропишутся все библиотеки, которые наш пакет потребует, но вы также можете указать пакеты вручную. Rpm также автоматически прописывает зависимости perl, python, mono и некоторые другие (все эти зависимости прописываются не в spec-файл разумеется, а в сам пакет). Если вам не нужно, чтобы зависимости прописывались автоматически, следует прописать в spec-файл новый тег AutoReq: no. Обычно его прописывают при сборки проприетарных программ, так как rpm добавляет внутренние зависимости из собираемой программы.

В нашем примере используются конструкции Requires(post) и Requires(postun) для зависимостей в скриптах установки и удаления. В принципе достаточно и простого Requires. Здесь особенно нечего комментировать. Просто самому StarDict в процессе работы эти зависимости не нужны. Нужны они только при инсталляции и удалении.

Есть ещё несколько полезных тегов, которые здесь не используются.

Provides: название1, название2

• другие названия, помимо ***%{name} ***, на которые будет откликаться данный пакет. Удобно указывать, если вы сменили название пакета, а другие пакеты продолжают зависеть от старого названия.

Obsoletes: название1, название2

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

Conflicts: название1, название2

— перечисляются пакеты, которые конфликтуют с текущим. Подразумевается что указанные пакеты нужно вручную удалить, перед установкой нашего. Также используются конструкции со знаками сравнения и версиями (см. выше).

Suggests: название1, название2

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

Epoch: число

— обычно или не указывается совсем или равняется 0. Суть этого параметра вот в чем. Пусть всё наш же пакет stardict имеет версию 2.4.8, а также есть более старый 2.4.5. Так вот если ***%{epoch} ***у stardict 2.4.5 будет 1, а у 2.4.8 - 0, то пакет 2.4.5 будет всегда новее, чем 2.4.8. О чём при установки вам RPM и скажет. Этот параметр удобен, если вы хотите откатиться на предыдущую версию (разумеется, если вы это все выкладываете в публичный репозиторий и хватаете все через urpmi или rpmdrake. Для «домашних» нужд подойдёт параметр к rpm --force). Если определён тег Epoch: 0, то пакет будет иметь приоритет перед пакетом с непоределённым тегом Epoch.

BuildArch: архитектура

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

ExclusiveArch: архитектура1 архитектура2

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

На этом шапка заканчивается и начинаются отдельные секции.

%description

StarDict is an international dictionary written for the GNOME environment.

It has powerful features such as "Glob-style pattern matching," "Scan

seletion word," "Fuzzy search," etc.

Описание главного пакета, того, у которого будет имя ***%{name} ***

%package tools

Summary: StarDict-Editor

Requires: %{name} = %{version}-%{release}

Group: User Interface/Desktops

Здесь мы создаём новый пакет, название которого будет %{name}-tools. Если нужно обозвать пакет совсем по другому, то следует сделать, например, так: %package -n tools-stardict. Версия нового пакета берётся из заданного тега Version. Обратите внимание на Requires. В нём прописана зависимость на главный пакет stardict. Если бы он имел ***%{epoch} ***, то необходимо было бы обязательно указать ***Requires: %{name}-%{epoch}:%{version}-%{release} ***. Иначе вам просто не удастся установить это пакет.

%description tools

A simple tool for StarDict.

Описание второго пакета

%prep

%setup -q -a1

%patch0 -p1

Секция %prep в ней начинается подготовка к сборке. %setup распаковывает исходники. Опция -q не показывает вывод распаковывания архива. Опция -a1 используется для распаковки ***%{SOURCE1} ***, второго тарбола внутрь(!) каталога первого тарбола. Соответственно цифра указывает на номер SOURCE. Ещё иногда используется параметр -b, тогда второй тарбол распаковывается в тот же каталог, что и первый. Соответственно если у нас один тарбол, то опции -a, -b не используются.

Если у вас первый каталог в тарболе имеет отличное от %{name}-%{version} название, то rpm не сможет войти автоматом в этот каталог. В таком случае следует немного изменить %setup. Если в архиве stardict-2.4.8.tar.bz2 первый каталог имеет название, например, просто stardict, то выглядеть это будет так:

%setup -q -n %{name} -a1

Сразу после распаковки пакета, перед %patch, если нужно, можно скопировать файлы, или запустить какие либо программы для изменения исходников. Допустим скопировать файл русификации, или подправить sed’ом какой-нибудь исходник. Просто вызываете здесь cp, sed или ещё что-то. В качестве корня здесь выступает каталог, в который распаковался первый тарболл (за него отвечает переменная $RPM_BUILD_DIR, но она крайне редко используется).

При помощи %patch накладываются патчи. Если вы делали патч, как мы писали выше, то у вас всегда будет параметр -p1. Также часто используют параметр -b .название_патча, для создания резервной копии.

%build

pushd %{name}-tools-%{version}

%configure

%make

popd

%configure

%make

Секция %build, именно здесь происходит сборка пакета. Обратите внимание на pushd и popd. Этими командами мы переходим и выходим из каталога второго тарбола. Именно он будет корневым каталогом после pushd. После команды popd мы вернёмся в каталог первого тарбола. Соответственно если у вас один исходник, то не нужно использовать эти команды.

Так как у нас две программы в одном пакете, то мы выполняем два раза концигурацию %configure и два раза make. Если пакет конфигурируется при помощи autotools, то макросом %configure запускается скрипт configure из корня распакованного тарбола. У него обычно бывает много параметров, их можно посмотреть из командной строки при помощи ./configure --help. После %configure вы можете указать нужные вам параметры. Заметьте, что вызов %configure и ./configure отличаются. В первом случае конфигуратору будут переданы правильные каталоги для инсталляции (а также стандартные параметры), во втором - каталоги по умолчанию.

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

Если пакет не использует autotools, то %configure, а может и %make использовтаь не нужно, для сборки прочтите файл README и INSTALL. В РОСЕ есть макросы и на другие случаи жизни - например, %cmake для одноименного инструмента сборки.

Когда сборка успешна закончена, в действие вступает секция %install.

%install

pushd %{name}-tools-%{version}

%makeinstall_std

popd

%makeinstall_std

%find_lang %{name}

%%find_lang, поиск файлов локализации. Параметром у неё является название файлов, которые будут лежать после установки в каталоге %{buildroot}/usr/share/locale/*/LC_MESSAGES/*.mo. Обычно оно соответствует ***%{name} ***. Если это не так, пишите другое имя.

Во многих spec-файлах вы можете заметить выполнение команды rm -rf %{buildroot} или rm -rf $RPM_BUILD_ROOT в самом начале секции %install, а также секцию %clean с такими же строками. В современной РОСЕ в этом нет необходимости, такая зачистка выполняется автоматически.

%preun

%preun_uninstall_gconf_schemas %{name}

Секции для установочных скриптов. Вообще их бывает несколько. %pre — выполняется перед установкой, %post — после установки, %preun — перед удалением, %postun — после удаления. В нашем примере при удалении удаляются схемы Gconf. Здесь мы предполагаем, что в пакете только одна схема и ее имя совпадает с именем пакета. Обратите внимание, что для удаления схем мы вызываем специальный макрос; этот макрос раскрывается rpmbuild РОСЫ в набор необходимых команд оболочки Shell, которые, собственно, и удаляют схему. Установка схем при установке пакета выполняется автоматически за счет файловых триггеров RPM.

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

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

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

Для определения каталогов используются специальные макроопределения.

• ***%{_prefix} ***— /usr
• ***%{_sysconfdir} ***— /etc
• ***%{_bindir} ***— /usr/bin
• ***%{_datadir} ***— /usr/share
• ***%{_libdir} ***— /usr/lib или /usr/lib64 в зависимости от разрядности системы
• ***%{_lib} ***— соответственно /lib или /lib64
• ***%{_libexecdir} ***— /usr/libexec
• ***%{_includedir} ***— /usr/unclude
• ***%{_mandir} ***— /usr/share/man
• ***%{_sbindir} ***— /usr/sbin
• ***%{_localstatedir} ***— /var.

%files -f %{name}.lang

%defattr(-, root, root)

%doc AUTHORS COPYING INSTALL README NEWS

%{_sysconfdir}/gconf/schemas/stardict.schemas

%{_bindir}/stardict

%{_bindir}/stardict-editor

%{_libdir}/bonobo/servers/GNOME_Stardict.server

%{_datadir}/applications/*.desktop

%{_datadir}/stardict

%{_datadir}/locale/*/LC_MESSAGES/*

%{_datadir}/pixmaps/stardict.png

%{_datadir}/gnome/help/%{name}/*

%{_datadir}/idl/GNOME_Stardict.idl

%{_datadir}/omf/*

%doc %{_mandir}/man?/*

%doc помечает файлы как документацию. Третья строка копирует указанные файлы в каталог %{_datadir}/doc/%{name}-%{version} . По умолчанию файлы в rpm пакете будут иметь владельцем root’а, а права доступа у низ будут такие же, как и в процессе установки. Если это необходимо поменять, то воспользуйтсь конструкцией %defattr.

Далее просто перечисляются файлы.

%files tools

%{_bindir}/stardict-editor

Тоже самое для пакета stardict-tools. Если бы он назывался tools-stardict, то %files выглядел бы так:

%files -n tools-%{name}.

Последнее, что идёт в spec-файле, это %changelog. В changelog’е вы указывает изменения в пакете по сравнению с предыдущей версией. Синтаксис его примерно следующий.

%changelog

* Sun Apr 22 2007 Your Name <your@email> - 2.4.8-4

• update desktop patch

** Макроопределения**

Теперь пора познакомиться поближе с макросами и переменными. Допустим, мы собираем пакет из SVN, в данном случае в релиз обычно включается дата ревизии. В самом начале spec-файла нужно определить переменную date:

%define date 20070612

Как мы видим, за определение переменных отвечает макроопределение %define. Теперь в любом месте spec-файла мы можем использовать нашу переменную в виде ***%{date} ***(скобки не обязательны, но в РОСЕ принято брать в скобки переменные, и не брать - макроопределения; так их проще различать). Например, определение основных параметров будет выглядеть примерно так:

Version: 0.5

Release: 0.svn%{date}.3

Обратите внимание, что перед датой стоит 0., а после даты - число, которое и увеличивается при необходимости поднять релиз. Зачем так сделано? Когда наконец выйдет окончательная версия (в нашем случае - 0.5), ревизию можно будет убрать, а в релиз прописать просто 1. При этом литерально 1 больше, чем любая строка, начинающаяся на 0, и пакет будет считаться более новым, чем предварительные пакеты, собиравшиеся на основе ревизий SVN.

Крайне популярным макроопределением является конструкция

%if условие

действие1

%else

действие2

%endif

или просто %if без %else. Суть проста, если условие стоящее при %if истина, то выполняется действие1, в противном случае выполняется действие2.

Допустим, мы опять же собираем что-нибудь из SVN. Обычно внутри архива, если он из SVN, вместо каталога ***%{name}-%{version} ***указывают просто ***%{name} ***(архив sim-0.9.5.tar.bz2 внутри имеет каталог sim, так как финального релиза sim 0.9.5 не существует. Конечный же релиз будет иметь первым каталогом sim-0.9.5). Чтобы всякий раз не переписывать spec-файл, можно сделать следующие макроопределения:

%define svn 1

...

%prep

%if %{svn}

%setup -q -n %{name}

%else

%setup -q

%endif

Если переменная svn не определена, то будет выполняться часть сценария после %else. Можно также использовать более строгое условие (не забудьте про кавычки):

%define svn 1

...

%prep

%if "%{svn}" == "1"

%setup -q -n %{name}

%else

%setup -q

%endif

Внутри всех секций spec-файла мы можем использовать любые команды Linux, без каких либо «наворотов», а вот в шапке файла не всё так просто. Например, нам нужно определить версию firefox для пакета (допустим epiphany) и прописать ее в секцию Requires:. Выглядеть это будет следующим образом:

Requires: firefox = %(rpm -q firefox --qf "%%{version}")

Обратите внимание на то, что внешняя команда выполняется в %() (почти, как в bash - $()) и в spec-файле необходимо ставить два знака % в параметрах. Таким образом можно вызывать любые команды Linux, например, для определения версии ядра.

Ещё одним популярным макроопределение является конструкция %ifarch .. %endif. Если архитектура соответствует указанной после %ifarch, то выполняется какое либо действие. Архитектуры бывают i386, i486, i586, i686, i?86, x86_64, и понятное дело некоторые другие, с которыми вы наверно не столкнётесь.

Как уже отмечалось выше во всех секциях spec-файла вы можете использовать любые команды Shell, включая for, while, if и др.

Сборка пакета

Теперь перейдём непосредственно к сборке пакета. Исходники и патчи должны лежать в каталоге SOURCES, а spec файл в каталог SPECS. После этого нужно отдать команду:

rpmbuild -ba файл.spec

После этого пакет соберётся (или не соберётся, а вывалится с ошибками), и в подкаталогах каталога RPMS появятся бинарные пакеты, а в каталоге SRPMS появится исходник.

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

• Добавить в секцию %files макроопределение

%exclude путь_к_файлу/файл

• Добавить в начало spec-файла макроопределение

%define _unpackaged_files_terminate_build 0

Если необходимо собрать только бинарник или только исходник, то вместо -ba следует использовать -bb и -bs соответственно. Из полезных параметров rpmbuild можно отметить -clean (удалить весь мусор), -rmsource (удалить исходники из каталога SOURCE) и -target=архитектура (собрать пакет под конкретную архитектуру).

Можно также выполнять сценарии только в определённой секции. Описывать подобные параметры мы здесь не будем, см. man rpmbuild.

Сборка RPM пакета из уже установленного в системе

Иногда случается ситуация, что какой-то пакет уже установлен в системе (может быть в очень старой системе) и очень хочется получить rpm’ку с ним, а она как раз и не сохранилась. Также может захотеться собрать по быстрому пакет с изменёнными под ваши нужды конфигурационными файлами.

Для решения этой проблемы следует воспользоваться утилитой rpmrebuild. Эта написанная на bash утилита доступна в contrib-репозитории РОСЫ.

Работать с ней крайне просто. Нужно отдать всего лишь команду:

rpmrebuild название_установленного_пакета

Если какой-либо файл был изменён, то вам об этом сообщат, но процесс сборки не прервётся.

Rpmrebuild обладает огромным количеством параметров, например, вы можете изменять release пакета, changelog, скрипты, секции Requires, описания пакета и многое другое. Можете даже просто напросто изменить spec-файл, который скрипт сгенерирует сам. Он правда будет немного страшный, но это все же лучше, чем ничего.

Все параметры можно посмотреть при помощи

rpmrebuild --help

и

rpmrebuild --help-plugins

См. также:

Основы RPM

Создание пакетов ROSA

Глава 2. Сборка RPM-пакетов «с нуля» (теория и практика)

2.2. Основы RPM

--

Предисловие

Предполагается, что читатель имеет опыт использования 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 может не работать в других дистрибутивах, хотя разработчики делают всё возможное, чтобы дистрибутив оставался совместимым с Red Hat (а следовательно, и Fedora).

Сборка пакетов для 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

# При подготовке пакетов для Росы, не создавайте раздел %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

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

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

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

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

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

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

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

---

---

Таблица A-1. Значение параметра, передаваемого pre и post скриптам

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

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

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

%postun

if [ $1 = 0 ]; then

// Выполнение действий, специфичных для удаления пакета

fi

if [ $1 = 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

• Статья IBM по сборке rpm
• Статья из журнала redhat по сборке rpm
• Учебное пособие в формате Pdf, созданное GuruLabs, по сборке rpm
• Руководство RPM Red Hat
• CentOS how to setup RPM Build Environment

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

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

...ПРОДОЛЖЕНИЕ СЛЕДУЕТ...