Построение пакета RPM для Rosa Linux на практике

Если Вы уже давно пользуетесь операционной системой Linux и хоть немного разбираетесь в программировании, рано или поздно Вам может понадобиться собрать программу из исходного кода. Может быть, нужной программы не окажется в репозиториях дистрибутива. Или в этих репозиториях программа старой версии, а Вам нужна самая свежая. А может, Вы создали новую программу и хотите поделиться ей с другими пользователями.

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

Надеюсь, эта статья поможет быстрее разобраться со сборкой пакета RPM для Rosa Linux или для другого дистрибутива, использующего менеджер пакетов RPM (Mandriva, RedHat). Или хотя бы подскажет, где искать информацию.

Здесь я покажу, как создавать пакеты RPM на своём локальном компьютере, на простом примере. Будем собирать программу xkb-switch в операционной системе Rosa Linux. Исходники программы будем брать с GitHub.

Немного о Rosa Linux

Rosa Linux — дистрибутив, созданный и поддерживаемый российскими разработчиками. Он сделан на основе Mandriva, но с некоторыми особенностями. Я использую 32-битную версию Rosa Fresh R8, которая выпущена в 2014 году. Сейчас версия R8 уже не поддерживается разработчиками (репозитории для неё не обновляются), но хорошо работает на моём ноутбуке, поэтому не хочется устанавливать новую версию.

Rosa Fresh R8 Использует рабочий стол KDE4. Все версии дистрибутива используют для управления пакетами с приложениями менеджеры rpm и urpm, и соответствующие команды: rpm, urpmi, urpme, urpmq, urpmf.

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

Построение пакетов в Rosa Linux немного проще, чем в некоторых других дистрибутивах, основанных на RPM. Некоторые моменты автоматизированы и не нуждаются в настройке.

Немного об xkb-switch

Мне понравилась идея использовать плагин для текстового редактора Vim — xkbswitch, о котором есть статья на Хабре. Он автоматически переключает раскладку клавиатуры на английский язык при выходе из режима ввода, и обратно — на тот, на котором вводили текст в прошлый раз — если войти в режим ввода снова. Для работы этого плагина нужна программа xkb-switch, которая позволяет переключать раскладку клавиатуры из командной строки и из плагинов для редактора Vim. В репозиториях Rosa Linux R8 этой программы не оказалось (и, скорее всего, никто не будет его добавлять, ведь дистрибутив уже старый, а программа xkb-switch не слишком популярна).

Настройка, доработка, проверка программы

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

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

Проверяем исходный код без своего профиля в GitHub

Если Вы решили поработать с исходным кодом или настройками компиляции проекта, но у Вас нет своего профиля в GitHub или не хочется его использовать, можно просто скачать и распаковать исходный код. В нашем случае это могло бы выглядеть так (я использую папку ~/Projects/cpp для исходных кодов на C++):

cd ~/Projects/cpp
git clone https://github.com/ierton/xkb-switch.git

Это создаст папку ~/Projects/cpp/xkb-switch, содержащую исходный код. Конечно, вместо использования git можно скачать архив с программой и распаковать его.

Из файла README.md в папке проекта несложно догадаться, что для сборки программы используется утилита cmake. Поэтому если нужно изменить настройки компиляции — в нашем случае они находятся в файле CMakeLists.txt. А мы просто попробуем скомпилировать программу и проверить, работает ли она. Какие команды для этого нужно использовать, написано в том же файле README.md в корне проекта.

cd xkb-switch
mkdir build && cd build
cmake ..
make
./xkb-switch
#здесь должно быть выведено имя текущей группы раскладок клавиатуры
./xkb-switch -l
#здесь должны быть выведены все доступные группы
./xkb-switch -s ru
#после этого раскладка должна переключиться на русскую (если она есть)

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

cd ~/Projects/cpp/xkb-switch
rm -rf ./build
cd ~/Projects/cpp
zip -r xkb-switch.zip xkb-switch

Файл xkb-switch.zip потом нужно будет использовать для сборки пакета.

Проверка с сохранением проекта в свой профиль GitHub

Я предполагаю что тот, кто читает этот раздел, хоть немного знаком с работой с git и уже завёл себе профиль в GitHub. Считаю этот способ самым лучшим, поэтому в оставшейся части статьи будет подразумеваться, что используется именно он, если не сказано другое.

Сначала нужно «форкнуть» оригинальный проект в свой GitHub. После этого, как в прошлом способе, клонируем проект к себе на компьютер, но уже из своего репозитория (в моём случае, имя пользователя — alexandersolovyov):

cd ~/Projects/cpp
git clone https://github.com/alexandersolovyov/xkb-switch.git

Для добавления любых изменений, лучше использовать новую ветку. Тогда при желании можно будет использовать разные версии программы. А ещё можно будет предлагать свои изменения автору проекта с помощью pull-request'ов. Например, если Вы решили немного исправить файл CMakeLists.txt, перед этим нужно создать новую ветку с помощью:

git branch cmake_corrections

После того, как изменения сделаны, проверены и добавлены в ветку (с помощью git commit -am "описание изменений"), можно добавить новую ветку в свой GitHub:

git push origin cmake_corrections

После этого можно сделать pull-request, если это нужно.

Можно сделать ссылку на оригинальный репозиторий:

git remote add ierton https://github.com/ierton/xkb-switch.git

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

git pull ierton master

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

Source0: https://github.com/ваше-имя/имя-проекта/archive/имя-ветки-с-исправлениями.zip

Но, как подсказал пользователь specblog, вообще-то так делать неправильно. Лучше передать свои изменения в виде патчей. Для этого нужно создать файлы патчей из изменений в своей ветке и скопировать их в папку с исходниками для сборки пакета (~/rpmbuild/SOURCES/). Потом нужно будет указать их в спек-файле. Это мы рассмотрим немного позже, но если хотите — можно прочитать здесь. Если Вы не знаете, как создавать патчи, — можно заглянуть под спойлер.

git format-patch -o ~/rpmbuild/SOURCES origin/master

git format-patch -o ~/rpmbuild/SOURCES -2

git format-patch -o ~/rpmbuild/SOURCES master..cmake_corrections

mv 0001-Return-memory-allocated-by-XkbRf-getNamesProp()-for-tmp.patch 001-Fix-memory-leak.patch

Подготовим «рабочее место» для создания пакета

Для начала нужно создать структуру каталогов. Вся сборка происходит в папке rpmbuild в домашней папке пользователя. Создадим начальную структуру каталогов и перейдём в папку для спек-файлов:

mkdir -p ~/rpmbuild/SPECS && cd ~/rpmbuild/SPECS

Для Rosa Linux этого достаточно: остальные папки будут созданы автоматически.

В другом дистрибутиве для построения пакета может использоваться другое расположение файлов. А ещё, может быть, придётся создать всю иерархию папок вручную. Ищите информацию для Вашего дистрибутива, если Вы используете не Rosa Linux. Например, вот так это может выглядеть в Red Hat.

Если пакет собран с ошибками, то все файлы, созданные командой rpmbuild, не удаляются — так же, как и при успешной сборке. Мы будем пытаться собирать пакет много раз, и файлы, оставшиеся после прошлого раза, будут мешать. Поэтому лучше сделать простой скрипт, который поможет быстро их удалять. Создадим файл cleanup.sh и поместим его в папку ~/rpmbuild/SPECS. Вот его содержимое:

!#/bin/sh
rm -rf ~/rpmbuild/BUILD/*
rm -rf ~/rpmbuild/BUILDROOT/*
rm -rf ~/rpmbuild/RPMS/*
rm -rf ~/rpmbuild/SRPMS/*

Конечно, лучше добавить для него право исполнения с помощью команды chmod u+x cleanup.sh.

Если Вы хотите собрать пакет из файлов, которые находятся на локальном компьютере, — если Вы не используете GitHub и сделали изменения в файлах проекта, или хотите создать пакет из своей собственной программы, которая хранится только на Вашем компьютере, — нужно упаковать проект в архив (например, .zip, .tar или .tar.gz) и поместить его в папку SOURCES. Например, так:

cd ~/Projects/cpp/
zip -r xkb-switch.zip xkb-switch
mkdir -p ~/rpmbuild/SOURCES
cp xkb-switch.zip ~/rpmbuild/SOURCES/

Если после сборки программы Вы захотите собрать ещё одну или ту же самую, но другой версии, то нужно будет удалить все файлы из папки ~/rpmbuild/SOURCES, и уже после этого скопировать туда свой архив (если Вы не скачиваете его с GitHub) и файлы патчей (если они используются). Иначе файл архива, скорее всего, не будет скачиваться с GitHub (почему — увидим позже), а также будет тяжело разобраться в том, какой файл патча какой программе принадлежит.

Начнём создавать спек-файл

Основа построения пакета RPM — так называемый спек-файл. Этот файл содержит инструкции для программы rpmbuild (вернее rpm), необходимые для сборки пакета.

Создадим файл xkb-switch.spec в папке ~/rpmbuild/SPECS/. Проще всего начать с шаблона, который можно найти на сайте Template Spec Files.

Из файла README на странице проекта xkb-switch известно, что программа компилируется с помощью утилиты cmake. Поэтому выберем Spec file for a program built using CMake и скопируем весь шаблон в наш спек-файл. Конечно, для того, чтобы правильно собрать наш RPM-пакет, этот шаблон нужно сильно изменить, чем мы и займёмся.

Немного о синтаксисе спек-файла

• Синтаксис спек-файла позволяет добавлять комментарии в стиле bash.
  
• В качестве промежутков между значениями в одной строке, чтобы создать вид ровных колонок, можно использовать пробелы, но документация настойчиво рекомендует использовать символ табуляции (один или два — сколько нужно, чтобы колонки были ровными). Внимание: во всех примерах кода в этой статье использованы только пробелы, поэтому лучше не копировать весь текст отсюда в свой спек-файл, а печатать самостоятельно.
  
• Поля-опции состоят из специального имени опции с двоеточием и следующего через табуляцию (или пробелы) значения. Регистр символов в названиях полей не имеет значения. Например:
  

      Name: xkb-switch
      

  
  
• Если перед словом стоит символ % (например, %description), то это — специальное ключевое слово. Оно может быть вызовом команды, макроса или скрипта. Тогда после него могут быть указаны параметры, которые он использует. А есть ключевые слова, которые обозначают начало блока команд или опций. Тогда рядом с ним могут быть указаны параметры, а на следующих строках должны быть команды или список опций, которые я описал в предыдущем пункте. После такого блока должна быть оставлена пустая строка.
  
• Чтобы использовать значение константы, нужно вставить в любое место конструкцию вида %{имя_константы}. Её значение может быть предопределённым, а может определяться опцией (например, Name: xkb-switch) или с помощью ключевого слова %define. Все эти константы тоже считаются макросами. Подробнее их использование будет рассмотрено ниже.
  

Заголовок спек-файла

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

# CMake версии 2.6 и выше
BuildRequires: cmake >= 2.6
# Компилятор C/C++
BuildRequires: gcc
# Заголовочные файлы библиотеки libxkbfile
BuildRequires: libxkbfile-devel
# От библиотеки X11 уже зависит libxkbfile,
# поэтому libx11-devel указывать не нужно.
# Архиватор для файла man:
BuildRequires: xz
    

%description
xkb-switch is a C++ program that allows to query and change the keyboard layout
state for X11 Window System (XKB) via command line. It provides a command
'xkb-switch', and bindings for API of the Vim text editor via
'libxkbswitch.so'. It is mainly used by a plugin for Vim text editor,
vim-xkbswitch. Originally ruby-based code written by J.Broomley.
    

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

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

Подготовка исходников

Первым идёт блок %prep, в котором указываются команды для подготовки к компиляции. В нём — команда-макрос %setup. Она запускает скрипт, который делает следующее:

• Скачивает архивы с файлами исходного кода программы, указанные опциями с именами вида SourceX: в заголовке файла (у нас — только Source0:). Если файл уже скачан или указано только имя файла, то ничего не скачивается.
  
• Скачанные файлы сохраняются в папку ~/rpmbuild/SOURCES/.
  
• Распаковывает эти архивы в папку ~/rpmbuild/BUILD/.
  
• Переходит в папку с распакованными файлами.
  

Её опция -q указывает, чтобы выводилось меньше информации в процессе выполнения.

Можно сразу попробовать собрать пакет, останавливаясь после выполнения блока %prep:

rpmbuild -bp ~/rpmbuild/SPECS/xkb-switch.spec

Для сборки используется команда rpmbuild. Если в Вашей системе нет этой команды, то вместо неё можно использовать rpm с теми же опциями: rpmbuild это её ограниченный синоним, который предназначен только для построения пакетов. Все команды для сборки нужно выполнять от имени обычного пользователя (не от имени root и без команды sudo). Описание всех опций rpmbuild можно увидеть, выполнив man rpmbuild. Там же можно увидеть список папок, в которых находятся макросы и другие файлы, используемые этой командой, — на случай, если Вам захочется подробнее разобраться в порядке работы команды rpmbuild.

В результате получим сообщение об ошибке: xkb-switch-1.6.0: No such file or directory. По выводу команды видно, что после распаковки архива скрипт пытается перейти в папку ~/rpmbuild/BUILD/xkb-switch-1.6.0, которой нет. Выполнив команду

ls ~/rpmbuild/BUILD/

Видим, что там находится папка xkb-switch-master. Её нужно указать команде %setup с помощью опции -n. В результате блок %prep в спек-файле должен выглядеть так:

%prep
%setup -q -n xkb-switch-master

Выполним наш скрипт ~/rpmbuild/SPECS/cleanup.sh, чтобы очистить папку BUILD, и попробуем снова построить пакет, заканчивая блоком %prep. Теперь видим, что последним сообщением выводится exit 0. Это значит, что блок выполнен без ошибок.

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

%apply_patches

После этого попробуйте ещё раз выполнить rpmbuild -bp xkb-switch.spec. Если обнаружатся ошибки — их нужно будет исправить.

Подробнее о добавлении патчей можно почитать на сайте Maximum RPM.

Теперь можно двигаться дальше.

Компиляция

Компиляция исходного кода выполняется блоком %build. В файле README проекта сказано, что компиляция делается командами cmake .. и make, но в нашем шаблоне спек-файла используются одноимённые макросы. Это правильно: так команды будут выполнены со всеми переходами в папки и опциями, которые нужны для правильной компиляции. Оставим всё как есть, очистим папки и выполним построение до пункта %build включительно:

~/rpmbuild/SPECS/cleanup.sh
rpmbuild -bc ~/rpmbuild/SPECS/xkb-switch.spec

В конце вывода видим exit 0: всё сделано без ошибок.

Вообще, в блоках команд не обязательно использовать только одни макросы. Можно добавить любые команды shell (то есть bash или zsh, или что там у Вас). Команда rpmbuild во время сборки перемещается по папкам, поэтому нужно добавить переход в правильную рабочую папку перед своей командой. В этих командах shell можно использовать константы спек-файла — как и в любом другом месте этого файла. (Использование констант мы увидим ниже.)

Если Вам нужно собрать какой-нибудь необычный пакет, тогда, скорее всего, придётся использовать в блоке %build команды shell вместо макросов.

Изменить опции компиляции для проекта, не изменяя его файлов, может быть сложно. Если для сборки используется команда cmake, то, возможно, для этого придётся изучить содержимое файла макроса %cmake и составить группу команд для спек-файла таким образом, чтобы они делали то же самое, но с необходимыми изменениями. Обычно гораздо проще изменить файл настроек компиляции проекта (в нашем случае — CMakeLists.txt). Вот поэтому я рекомендовал использовать свою копию проекта или папки с исходным кодом, сделав там необходимые изменения.

Инсталляция

Вернее, псевдоинсталляция. В блоке %install должны выполниться действия, в результате которых скомпилированные файлы программы будут находиться в папках с точно такой же иерархией, как у корневой папки системы, но внутри папки ~/rpmbuild/BUILDROOT/полное_имя_пакета-buildroot/.

Здесь полное_имя_пакета будет состоять из имени, указанного с помощью опции Name: в заголовке спек-файла, версии программы (Version: в спек-файле), номера релиза (Release: в спек-файле), названия дистрибутива, его версии и архитектуры процессора.

В файле README проекта написано, что установка выполняется командой make install, находясь в папке build внутри папки проекта. В спек-файле команда-макрос %makeinstall_std -C build делает то же самое, но более правильно. Построим проект до пункта инсталляции включительно (как всегда, сначала очистив папки):

~/rpmbuild/SPECS/cleanup.sh
rpmbuild -bi ~/rpmbuild/SPECS/xkb-switch.spec

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

Упаковка файлов

В сообщении об ошибке после псевдоинсталляции есть список файлов, которые ещё не отмечены в спек-файле для упаковывания. Этот же список можно узнать, просмотрев всё содержимое папки ~/rpmbild/BUILDROOT/. (Для этого, обычно, очень удобно использовать команду tree, которая по-умолчанию не установлена в большинстве дистрибутивов Linux.) Кроме файлов, о которых нам сказало сообщение об ошибке, там есть ещё файлы с расширением .debug. Для работы с ними, обычно, ничего не нужно настраивать: пакет с отладочными символами будет создан полностью автоматически.

Чтобы указать, какие файлы должны быть добавлены в пакет, нужен блок %files в спек-файле. Мы удалили строки, нужные для поддержки нескольких языков, поэтому такого блока в файле нет. Создадим его.

Во многих системах принято располагать блок %files внизу спек-файла. Это логично, ведь он выполняется последним. Но в Rosa Linux его принято писать сразу перед блоком %prep (и разделительной строкой-комментарием в нашем случае). Так все настройки, касающиеся подготовки файлов, будут находиться в конце файла, а то, что касается сборки пакета из этих файлов — в верхней части. Это особенно удобно если нужно построить несколько пакетов одним спек-файлом (да, так тоже можно делать, и мы рассмотрим это ниже).

В блоке %files должен быть список файлов, которые должны быть в пакете RPM. Итак, создадим блок над разделительной чертой:

%files
%{_bindir}/%{name}
%{_libdir}/libxkbswitch.so
%{_libdir}/libxkbswitch.so.1
%{_libdir}/libxkbswitch.so.%{version}
%{_mandir}/man1/%{name}.1.xz

Здесь для указания папок установки лучше использовать специальные макросы-константы. Их полный список, обычно, можно посмотреть в файле /usr/lib/rpm/macros. В частности, %{_bindir} вставляет путь к исполняемым файлам, %{_libdir} — к папкам библиотек, и %{_mandir} — к файлам документации man. А константы %{name} и %{version} содержат значения полей Name: и Version: в заголовке спек-файла.

Теперь попробуем построить пакет полностью:

~/rpmbuild/SPECS/cleanup.sh
rpmbuild -ba ~/rpmbuild/SPECS/xkb-switch.spec

… И получим 2 сообщения и 1 предупреждение. Их выдаёт команда rpmlint, которая автоматически выполняется после построения пакетов. Чтобы понять, что они значат, может помочь страница Rpmlint Errors Если коротко, они расшифровываются так:

Всё понятно? Не думаю. Давайте разберёмся подробнее, что здесь происходит.

Что такое rpmlint

После построения пакетов в Rosa Linux команда rpmbuild вызывает программу rpmlint, которая проверяет правильность сборки. Если rpmlint выдала сообщения об ошибках, это не значит, что пакет совсем непригоден к использованию. Она только проверяет, насколько пакет соответствует стандартам Rosa Linux (или другого дистрибутива, в котором была запущена rpmlint) и насколько правильно указаны зависимости.

Если Вы пользуетесь другим дистрибутивом, и проверка не запускается автоматически, тогда нужно проверить построенные пакеты вручную. Для этого нужно перейти в папку ~/rpmbuild/RPMS/архитектура_процессора/ и запустить для каждого построенного пакета команду вида rpmlint -i имя_файла_пакета.

Кстати, если Вы скачали готовый пакет RPM на сайте какого-нибудь проекта, то прежде, чем устанавливать такой пакет, можно проверить, насколько правильно он собран для Rosa Linux, с помощью той же команды rpmlint -i имя_файла_пакета.

Виды пакетов RPM для Rosa Linux

Пакеты для Rosa Linux делятся на 6 видов. В идеальном случае, каждый собранный пакет должен соответствовать только одному из этих видов.

Наш результат

Теперь всё стало яснее.

• В нашем пакете xkb-switch содержится файл libxkbswitch.so, который, по правилам, должен содержаться в пакете для разработки. Поэтому выдаётся сообщение, что файл для разработки находится не в пакете для разработки: xkb-switch.i586: W: devel-file-in-non-devel-package /usr/lib/libxkbswitch.so.
  
• Наш пакет распознан как библиотечный, ведь в нём есть файлы /usr/lib/libxkbswitch.so.1 и /usr/lib/libxkbswitch.so.1.6.0. Но также в нём есть исполняемый файл, которого в библиотечном пакете быть не должно. Отсюда ошибка: xkb-switch.i586: E: executable-in-library-package (Badness: 1) /usr/bin/xkb-switch.
  
• Наш пакет признан библиотечным, но в конце его имени нет первого числа версии (1). Поэтому получено сообщение: xkb-switch.i586: E: incoherent-version-in-name (Badness: 50) 1.
  

Сообщения, выданные rpmlint, не обязательно всегда полностью удовлетворять. Во многих случаях это бывает не нужно или даже невозможно. Особенности программы xkb-switch таковы, что она содержит библиотечный файл libxkbswitch.so.1.6.0 и ссылки на него только для того, чтобы его могли использовать плагины для редактора Vim. Эта библиотека разрабатывается и распространяется только одновременно и вместе с программой xkb-switch, и она не предназначена для использования другими программами на C или C++. Поэтому RPM-пакет можно считать успешно построенным.

В результате у нас получился такой спек-файл:

Summary:       Query and change XKB layout state
Name:          xkb-switch
Version:       1.6.0
Release:       1
License:       GPLv3+
Group:         Development/X11
URL:           https://github.com/ierton/xkb-switch
Source0:       https://github.com/alexandersolovyov/xkb-switch/archive/master.zip
BuildRequires: cmake >= 2.6
BuildRequires: gcc
BuildRequires: libxkbfile-devel
BuildRequires: xz

%description
xkb-switch is a C++ program that allows to query and change the keyboard layout
state for X11 Window System (XKB) via command line. It provides a command
'xkb-switch', and bindings for API of the Vim text editor via
'libxkbswitch.so'. It is mainly used by a plugin for Vim text editor,
vim-xkbswitch. Originally ruby-based code written by J.Broomley.

%files
%{_bindir}/%{name}
%{_libdir}/libxkbswitch.so
%{_libdir}/libxkbswitch.so.1
%{_libdir}/libxkbswitch.so.%{version}
%{_mandir}/man1/%{name}.1.xz

#------------------------------------------------------------------

%prep
%setup -q -n xkb-switch-master

%build
%cmake
%make

%install
%makeinstall_std -C build

Если нужно разделить пакет на части

Может понадобиться разделить проект на несколько пакетов — например, если библиотека из этой программы будет использоваться другой программой. Чтобы рассмотреть такой вариант, давайте представим, что нам нужно разделить файлы проекта xkb-switch на 3 пакета: исполняемый, библиотечный и для разработки. Тогда:

• в исполняемом пакете должен быть файл /usr/bin/xkb-switch и его документация /usr/share/man/man1/xkb-switch.1.xz,
  
• в библиотечном — файлы /usr/lib/libxkbswitch.so.1 и /usr/lib/libxkbswitch.so.1.6.0,
  
• а в пакете для разработки — /usr/lib/libxkbswitch.so.
  

Для этого нужно сделать изменения в спек-файле. О том, как это сделать,
можно узнать из соответствующего раздела онлайн-книги Maximum RPM. Также может быть полезен пример спек-файла для libxkbfile и Политика оформления библиотек Rosa Linux.

Давайте попробуем это сделать.

Добавим немного макросов

Для удобства работы можно добавить несколько макросов — по примеру спек-файла для libxkbfile. Добавим в начало нашего спек-файла такие строки:

%define major       1
%define libname     %mklibname xkbswitch %{major}
%define develname   %mklibname -d xkbswitch

Здесь ключевое слово %define объявляет константу. После этого слова через пробел следует название константы, а за ним (через один или два символа табуляции) — значение или макрос, результат выполнения которого будет присвоен имени константы. То есть первая строка обозначает, что в константе %{major} будет храниться 1, это будет первое число номера версии.

Макрос %mklibname берёт строку «lib», добавляет к нему первый аргумент, а к тому что получилось — второй аргумент (и все следующие). То есть значением константы %{libname} будет «lib» + «xkbswitch» + (значение константы %{major}) = libxkbswitch1 — имя пакета библиотеки.

Опция -d макроса %mklibname добавляет окончание -devel. Поэтому значением константы %{develname} будет libxkbswitch-devel — имя пакета для разработки.

Немного изменим заголовок

Приведём строку с опцией Version: к виду

Version:    %{major}.6.0

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

Теперь мы будем использовать заголовок спек-файла в качестве заголовка для пакета исполняемого файла. Поэтому можно немного изменить его описание. В итоге заголовок будет выглядеть так:

Name:          xkb-switch
Version:       %{major}.6.0
Release:       1
Summary:       Query and change XKB layout state
License:       GPLv3+
Group:         Development/X11
URL:           https://github.com/alexandersolovyov/xkb-switch
Source0:       https://github.com/alexandersolovyov/xkb-switch/archive/master.zip
BuildRequires: cmake >= 2.6
BuildRequires: gcc
BuildRequires: libxkbfile-devel
BuildRequires: xz

%description
xkb-switch is a C++ program that allows to query and change the keyboard layout
state for X11 Window System (XKB) via command line. It provides a command
'xkb-switch', and bindings for API of the Vim text editor, a library
'libxkbswitch'. It is mainly used for some plugins for Vim text editor, such as
vim-xkbswitch. Originally ruby-based code written by J.Broomley.

Определим пакеты библиотек

Оформим пакеты библиотек как под-пакеты для пакета с исполняемой программой. Под-пакеты это самостоятельные пакеты, каким-то образом связанные с основным пакетом (это будут отдельные файлы rpm). Определить их нам поможет ключевое слово %package. Рядом с этим словом нужно указать имя под-пакета. После этой строки следует блок, похожий на заголовок спек-файла. В каждом из этих блоков обязательно должны быть поля Version, Summary, Group. Также там могут быть опции Provides и Requires для указания Возможностей и Зависимостей пакета, которые не могут определиться автоматически. Поля Name быть не должно: имя пакета определяется именем, указанным рядом со словом %package.

У каждого пакета должно быть описание. Для этого используется блок %description с указанным рядом с ним именем — точно так же, как для соответствующего блока %package.

В Rosa Linux принято объявлять под-пакеты под блоком %description заголовка спек-файла. Определим пакет библиотеки libxkbswitch1так:

%package -n %{libname}
Version:  %{version}
Summary:  A library for xkb-switch tool, provides API bindings for Vim text editor
Group:    Development/X11

%description -n %{libname}
libxkbswitch library, required by xkb-switch tool. It provides bindings for API
of the Vim text editor, which can be used via 'libxkbswitch.so.1'.

Опция -n после ключевых слов %package и %description нужна, чтобы следующее слово полностью переписало название пакета. Без неё имя под-пакета будет дописываться через дефис к имени основного пакета, и название будет xkb-switch-libxkbswitch1. С этой опцией пакет будет называться libxkbswitch1. Всё остальное было описано раньше и должно быть понятно без объяснений.

Ниже объявим пакет для разработчиков:

%package -n %{develname}
Version:  %{version}
Summary:  Development library libxkbswitch, provides API bindings for Vim text editor
Group:    Development/X11

%description -n %{develname}
Development files for libxkbswitch. Provides bindings for
API of the Vim text editor via 'libxkbswitch.so'.

Определим файлы для пакетов

Теперь нужно определить, какие файлы будут в каких пакетах. Для этого используется блок %files.

На самом деле правила обозначения того, к какому пакету относится блок, одинаковы для блоков %package, %description и %files. Можно заметить, что для блока %description заголовка спек-файла имя пакета не указано. Если так делать, то блок считается принадлежащим основному пакету, в нашем случае — xkb-switch.

В спек-файлах для Rosa Linux обычно принято писать блоки %files под определениями пакетов, но перед блоком %prep. Наши блоки определения файлов будут выглядеть так:

%files
%{_bindir}/%{name}
%{_mandir}/%{name}.1.xz

%files -n %{libname}
%{_libdir}/libxkbswitch.so.%{major}
%{_libdir}/libxkbswitch.so.%{version}

%files -n %{develname}
%{_libdir}/libxkbswitch.so

Таким образом мы определили, что:

• в пакете xkb-switch будут файлы ~/usr/bin/xkb-switch и ~/usr/share/man/man1/xkb-switch.1,
  
• в пакете libxkbswitch1 будут файлы ~/usr/lib/libxkbswitch.so.1 и ~/usr/lib/libxkbswitch.so.1.6.0,
  
• а в пакете libxkbswitch-devel будет файл ~/usr/lib/libxkbswitch.so.
  

Теперь очистим папки с помощью скрипта cleanup.sh и попробуем построить пакеты с помощью rpmbuild -ba ~/rpmbuild/SPECS/xkb-switch.spec. В результате получим 3 предупреждения:

libxkbswitch1.i586: W: no-documentation

libxkbswitch-devel.i586: W: no-documentation

libxkbswitch-devel.i586: W: no-dependency-on
libxkbswitch/libxkbswitch-libs/liblibxkbswitch

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

Решение дополнительных проблем

Итак, чтобы убрать предупреждение об отсутствии документации, можно притвориться, что документация к библиотекам хранится в файле README.md проекта. Добавим его в блоки %files для пакетов библиотеки и разработки — с помощью макроса %doc:

%doc README.md

Здесь не нужно указывать полный путь. Рабочая папка макроса %doc — папка с распакованными исходниками. Поэтому в документацию пакетов будет добавлен файл ~/rpmbuild/BUILD/xkb-switdh-master/README.md.

Теперь у нас осталось только одно предупреждение: libxkbswitch-devel.i586: W: no-dependency-on libxkbswitch/libxkbswitch-libs/liblibxkbswitch. Оно обозначает, что у пакета libxkbswitch-devel нет зависимости от libxkbswitch или подобных.

С помощью команды rpm -qp опция имя-файла-пакета можно узнать любую информацию о файлах пакетов. Мы можем проверить предоставляемые возможности и зависимости между получившимися пакетами таким образом:

[user@pc ~] $ cd ~/rpmbuild/RPMS/i586/
[user@pc ~/rpmbuild/RPMS/i586] $ ls
libxkbswitch1-1.6.0-1-rosa2014.1.i586.rpm
xkb-switch-1.6.0-1-rosa2014.1.i586.rpm
libxkbswitch-devel-1.6.0-1-rosa2014.1.i586.rpm
xkb-switch-debuginfo-1.6.0-1-rosa2014.1.i586.rpm

[user@pc ~/rpmbuild/RPMS/i586] $ rpm -qp --provides libxkbswitch1-1.6.0-1-rosa2014.1.i586.rpm
libxkbswitch.so.1
libxkbswitch1 = 1.6.0-1:2014.1

[user@pc ~/rpmbuild/RPMS/i586] $ rpm -qp --provides libxkbswitch-devel-1.6.0-1-rosa2014.1.i586.rpm
devel(libxkbswitch)
libxkbswitch-devel = 1.6.0-1:2014.1

[user@pc ~/rpmbuild/RPMS/i586] $ rpm -qp --requires libxkbswitch-devel-1.6.0-1-rosa2014.1.i586.rpm
devel(libX11)
devel(libgcc_s)
devel(libstdc++)
devel(libxkbfile)
rpmlib(PayloadIsXz) <= 5.2-1

[user@pc ~/rpmbuild/RPMS/i586] $ rpm -qp --requires xkb-switch-1.6.0-1-rosa2014.1.i586.rpm
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1.3)
libgcc_s.so.1
libgcc_s.so.1(GCC_3.0)
libstdc++.so.6
libstdc++.so.6(CXXABI_1.3)
libstdc++.so.6(GLIBCXX_3.4)
libstdc++.so.6(GLIBCXX_3.4.11)
libstdc++.so.6(GLIBCXX_3.4.20)
libstdc++.so.6(GLIBCXX_3.4.9)
libxkbswitch.so.1
rpmlib(PayloadIsXz) <= 5.2-1

Отсюда видно, что пакет библиотеки libxkbswitch1 предоставляет возможности libxkbswitch.so.1 и libxkbswitch1. Пакет xkb-switch зависит от libxkbswitch.so.1, а вот у пакета libxkbswitch-devel нет зависимостей от libxkbswitch1. Это можно исправить, добавив зависимость в блок %package для libxkbswitch-devel. Теперь этот блок будет выглядеть так:

%package -n %{develname}
Version:  %{version}
Summary:  Development library libxkbswitch, provides API bindings for Vim text editor
Group:    Development/X11
Requires: %{libname} >= %{version}

Можно попробовать очистить папки и собрать пакеты заново, но… предупреждение об отсутствии зависимости всё равно останется. Если проверить зависимости пакета libxkbswitch-devel ещё раз, то увидим, что зависимость успешно добавляется. Скорее всего сообщение остаётся потому, что в нашем пакете для разработки нет заголовочных файлов, и rpmbuild не может определить эту зависимость автоматически.

Спек-файл, который у нас получился (с файлом README.md в качестве документации библиотек), — под спойлером:

%define major           1
%define libname         %mklibname xkbswitch %{major}
%define develname       %mklibname -d xkbswitch

# Main package. Automaticaly requires libxkbswitch and libxkbswitch-devel
Name:          xkb-switch
Version:       %{major}.6.0
Release:       1
Summary:       Query and change XKB layout state
License:       GPLv3+
Group:         Development/X11
URL:           https://github.com/alexandersolovyov/xkb-switch
Source0:       https://github.com/alexandersolovyov/xkb-switch/archive/master.zip
BuildRequires: cmake >= 2.6
BuildRequires: gcc
BuildRequires: libxkbfile-devel
BuildRequires: xz

%description
xkb-switch is a C++ program that allows to query and change the keyboard layout
state for X11 Window System (XKB) via command line. It provides a command
'xkb-switch', and bindings for API of the Vim text editor, a library
'libxkbswitch'. It is mainly used for some plugins for Vim text editor, such as
vim-xkbswitch. Originally ruby-based code written by J.Broomley.

# libxkbswitch
%package -n %{libname}
Version: %{version}
Summary: A library for xkb-switch tool, provides API bindings for Vim text editor
Group:   Development/X11

%description -n %{libname}
libxkbswitch library, required by xkb-switch tool. It provides bindings for API
of the Vim text editor, which can be used via 'libxkbswitch.so.1'.

# libxkbswitch-devel
%package -n %{develname}
Version:  %{version}
Summary:  Development library libxkbswitch, provides API bindings for Vim text editor
Group:    Development/X11
Requires: %{libname} >= %{version}

%description -n %{develname}
Development files for libxkbswitch. Provides bindings for
API of the Vim text editor via 'libxkbswitch.so'.

# xkb-switch
%files
%{_bindir}/%{name}
%{_mandir}/man1/%{name}.1.xz

# libxkbswitch1
%files -n %{libname}
%{_libdir}/libxkbswitch.so.%{major}
%{_libdir}/libxkbswitch.so.%{version}
%doc README.md

# libxkbswitch-devel
%files -n %{develname}
%{_libdir}/libxkbswitch.so
%doc README.md

#------------------------------------------------------------------

%prep
%setup -q -n xkb-switch-master

%build
%cmake
%make

%install
%makeinstall_std -C build

Вывод

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

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

Основные команды

Команды для сборки пакета

Проверка готового пакета

Можно проанализировать уже установленные пакеты с помощью тех же команд, но без опции p. А можно анализировать пакеты, которые находятся в репозиториях Rosa Linux, не устанавливая их. Сделать это поможет команда urpmq, подставленная вместо rpm -q. Например, urpmq -l имя_пакета выведет список файлов пакета, а urpmq --requires имя_пакета выведет его зависимости.

Полезные ссылки (основные источники)

1. Building RPMs — Quick Start — одна из лучших статей об основах создания пакетов RPM для Rosa Linux.
2. Основы RPM — статья на русском языке, похожая на предыдущую, но недоделанная и с несколькими мелкими ошибками. Помогла мне начать.
3. RPM: Синтаксис spec файла — соглашения об оформлении спек-файлов для Rosa Linux.
4. Maximum RPM — самая полная онлайн книга о работе с rpm и построении RPM-пакетов для RedHat Linux. В ней можно найти почти любую информацию об этом, но есть небольшие отличия от Rosa Linux. Хорошо использовать как справочник.
5. Template Spec Files — шаблоны файлов.spec. Чаще всего, с них лучше начинать создание спек-файла.
6. Automatic Build Farm (ABF) — сайт автоматической фермы построения пакетов Rosa Linux. С помощью строки поиска в шапке сайта можно найти по названию любой пакет, и посмотреть файлы, которые используются при его построении, в том числе .spec файл. Самый лучший источник примеров спек-файлов.
7. Rpmlint Errors — краткий справочник по ошибкам, которые выдаёт rpmlint.
8. Packaging Group — список категорий программ Rosa Linux.
9. Политика оформления библиотек Rosa Linux.
10. Git — перебазирование — альтернативный способ слияния веток в Git.