Создаём RPM пакеты для Fedora

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

Устройство SPEC файлов

SPEC файл — это своего рода манифест, на базе которого собираются RPM пакеты. В них подробно описывается процесс распаковки архивов с исходными текстами, непосредственно сборка и установка созданных бинарных файлов.

Именование

Имя SPEC файла должно строго соответствовать названию проекта и заканчиваться расширением .spec, например: foo-bar.spec. Если в названии упаковываемого проекта присутствуют пробелы, они должны быть заменены дефисами. Использование символа подчёркивания для этой цели не допускается.

Директивы

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

Обязательные директивы:

  • Name — название проекта;
  • Version — версия проекта;
  • Release — версия сборки пакета:
    • нумерация всегда начинается с 1 (для предрелизных версий допускается использовать значения меньше единицы, т.е. 0.1, 0.2 и т.д.);
    • увеличивается мейнтейнером на единицу при каждой сборке пакета в Koji;
    • при увеличении значения Version сбрасывается на 1;
    • всегда завершается макросом %{?dist};
  • Summary — короткое описание упаковываемого проекта:
    • строго на английском языке;
    • не должно быть длиннее 70 символов;
    • в конце точка не ставится;
  • License — лицензия проекта и всех его ресурсов:
    • если проект лицензирован под несколькими лицензиями, необходимо их указать последовательно, в качестве разделителя применяя оператор and;
    • необходимо указать все лицензии контента, используемого в проекте;
    • хорошим тоном считается указание соответствия каждой лицензии конкретному модулю проекта в виде комментария внутри спека;
    • мейнтейнеры должны самостоятельно следить за списком допустимых к использованию лицензий;
    • тексты всех использованных в проекте лицензий должны быть упакованы вместе с пакетом посредством модификатора %license секции %files;
  • URL — адрес в сети Интернет официального сайта проекта или его репозитория;
  • Source — имя архива с исходными текстами проекта:
    • должен включать полный URL для загрузки;
    • при невозможности указания прямой ссылки необходимо добавить инструкцию по его созданию в виде комментария;
    • проект может включать несколько архивов. В таком случае директива должна завершаться числом от 0 до MAXINT, например Source0, Source1, …, Source999.

Опциональные директивы:

  • Patch — позволяет включить патч, который будет накладываться на исходные тексты перед их сборкой:
    • все патчи должны быть загружены в VCS вместе со спеком;
    • аналогично Source, можно включать несколько патчей;
    • по общему правилу, патчи накладываются в порядке их следования;
  • BuildRequires — указывает имена пакетов, которые должны быть установлены в обособленном mock окружении перед началом сборки:
    • каждый пакет указывается отдельной директивой;
    • нумерация не применяется;
    • допускается указать номер версии. Поддерживаются операторы сравнения;
  • Requires — жёстко задаёт зависимость от конкретного пакета (включая виртуальные), либо файла. Должен применяться только при необходимости. Обычные зависимости от библиотек в пакет добавляются автоматически. Допускается номер версии;
  • Provides — указывает информацию о дополнительных компонентах, предоставляемых пакетом. Чаще всего применяется в связке с Obsoletes;
  • Obsoletes — сообщает о том, что данный пакет заменяет собой другой;
  • BuildArch — устанавливает архитектуру. В большинстве случаев применяется в архитектурно-независимых (noarch) пакетах;
  • ExclusiveArch — позволяет жёстко задать список архитектур, для которых будет собран данный пакет. Любые не указанные здесь будут проигнорированы сборочной платформой;
  • ExcludeArch — исключает указанные здесь архитектуры из сборки;
  • Recommends — указывает т.н. «слабые зависимости», т.е. опциональные пакеты, без установки которых пакет может исправно функционировать;
  • Epoch — задаёт эпоху пакета. Применяется если необходимо заменить пакет более высокой версии.

Секции

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

Обязательные секции:

  • %description — описание проекта:
    • строго на английском языке;
    • длина не ограничена;
    • должно заканчиваться точкой;
  • %prep — подготовка к сборке:
    • распаковывает архивы с исходными текстами;
    • применяет патчи;
  • %build — сборка пакета:
    • задаёт правильные флаги сборки;
    • выполняет последовательность команд для запуска сборки;
    • поддерживает готовые макросы для большинства сборочных систем;
  • %install — установка результата сборки:
    • выполняется автоматически посредством макросов для популярных сборочных систем;
    • при отсутствии готовой цели установка осуществляется посредством команды install;
  • %files — описывает все файлы внутри пакета:
    • допускается использовать символы подстановки (wildcards);
    • для текстов лицензионных соглашений применяется модификатор %license;
    • для файлов с документацией применяется модификатор %doc;
    • для различных файлов конфигурации — %config(noreplace);
    • может быть пустой если пакет не устанавливает никаких файлов (мета-пакет);
  • %changelog — список изменений в SPEC:
    • при каждом изменении значения директивы Release пакета должна быть добавлена соответствующая строка;
    • не допускается удаление предыдущих строк даже если они занимают очень много места;
    • должен содержать лишь список изменений внутри спека, поэтому не следует здесь указывать отличие между версиями проекта;
    • дата должна быть указана в правильном формате.

Опциональные секции:

  • %post — содержит скриптлет, который будет выполняться по окончании установки пакета;
  • %preun — содержит скриптлет, который будет выполняться перед удалением пакета;
  • %postun — содержит скриптлет, который будет выполняться по окончании удаления пакета;
  • %posttrans — содержит скриптлет, который будет выполняться по завершении транзакции;
  • %check — выполняет различные проверки, запускает тесты и т.д.

Автоматическая проверка

Для проверки валидности SPEC файлов рекомендуется применять утилиту rpmlint:

rpmlint foo-bar.spec

По результатам будет выдано заключение в виде ошибок (E), предупреждений (W) и сообщений (N). Ошибки обязательно следует исправить, предупреждения и сообщения можно игнорировать.

Подготовительная секция

Как уже говорилось выше, секция %prep предназначена для подготовки проекта к сборке. Для автоматической распаковки архивов с исходными текстами (тарболов) в большинстве случаев применяется макрос %autosetup, автоматизирующий это действие.

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

Опциональные параметры:

  • -p — аналогичен соответствующему параметру GNU Patch. Позволяет указать сколько вложенных каталогов следует отбросить при его применении;
  • -n — позволяет задать название корневого каталога внутри тарбола. Без его указания autosetup ожидает %{name}-%{version}, что часто не соответствует действительности.

Прочие тарболы (при их наличии) следует распаковать самостоятельно:

tar -xf %{SOURCE1}

Секция сборки

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

Рассмотрим самые популярные системы сборки:

  • GNU Automake:
    • %configure — задаёт флаги компиляции и автоматически вызывает ./configure скрипт. Если необходимо, можно добавить опциональные параметры через пробел;
    • %make_build — запускает процесс сборки в несколько потоков (в зависимости от количества доступных вычислительных ядер CPU);
  • Makefile:
    • %set_build_flags — задаёт флаги компиляции;
    • %make_build — запускает процесс сборки;
  • Cmake:
    • mkdir -p %{_target_platform} — создаёт каталог, в котором будет выполняться процесс сборки (в %prep);
    • pushd %{_target_platform} %cmake -G Ninja .. popd — переходит в каталог сборки, задаёт флаги компиляции и выполняет конфигурацию проекта. Если необходимо, можно добавить опциональные параметры для cmake через пробел;
    • %ninja_build -C %{_target_platform} — запускает сборку проекта с использованием Ninja;
  • Qmake:
    • mkdir -p %{_target_platform} — создаёт каталог, в котором будет выполняться процесс сборки (в %prep);
    • pushd %{_target_platform} %qmake_qt5 PREFIX=%{_prefix} CONFIG+=foo .. popd — переходит в каталог сборки, задаёт флаги компиляции и выполняет конфигурацию проекта;
    • %make_build -C %{_target_platform} — запускает сборку проекта;
  • Meson:
    • %meson — задаёт флаги компиляции и выполняет конфигурацию проекта;
    • %meson_build — запускает сборку проекта с использованием Ninja.

Секция установки

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

  • GNU Automake, Makefile, Qmake:
    • %make_install — выполняет стандартную цель install из сгенерированного Makefile. Опциональные параметры указываются через пробел;
  • Cmake:
    • %ninja_install -C %{_target_platform} — установка средствами Ninja;
    • %make_install -C %{_target_platform} — установка средствами Makefile если генеатор Ninja не применялся;
  • Meson:
    • %meson_install — установка средствами Ninja.

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

# Создаём каталог для размещения бинарника...
mkdir -p %{buildroot}%{_bindir}
# Устанавливаем бинарник...
install -m 0755 -p out/foo-bar "%{buildroot}%{_bindir}/%{name}"

Стандартные chmod для файлов и каталогов:

  • файлы:
    • 0755 — исполняемые;
    • 0644 — все остальные;
  • каталоги:
    • 0755 (можно не указывать при их создании средствами mkdir).

Если в проекте имеются локализации, то необходимо использовать макрос %find_lang для их поиска и добавления в секцию %files.

Если производилась установка AppStream или Desktop файлов, то в SPEC файле должна присутствовать секция %check с функциями их проверки:

appstream-util validate-relax --nonet %{buildroot}%{_datadir}/metainfo/%{name}.appdata.xml
desktop-file-validate %{buildroot}%{_datadir}/applications/%{name}.desktop

Примеры пакетов

Листинг простейшего проекта 1 с использованием GNU Automake:

Name: foo-bar
Version: 1.0
Release: 1%{?dist}

License: GPLv3+
Summary: Example application

URL: https://github.com/example/%{name}
Source0: %{url}/archive/v%{version}.tar.gz#/%{name}-%{version}.tar.gz

BuildRequires: desktop-file-utils
BuildRequires: libappstream-glib
BuildRequires: gcc-c++
BuildRequires: gcc

%description
Full description of our example application.

%prep
%autosetup -p1

%build
%configure
%make_build

%install
%make_install PREFIX=%{_prefix}

%check
appstream-util validate-relax --nonet "%{buildroot}%{_datadir}/metainfo/%{name}.appdata.xml"
desktop-file-validate %{buildroot}%{_datadir}/applications/%{name}.desktop

%files
%doc README.md
%license LICENSE
%{_bindir}/%{name}
%{_mandir}/man1/%{name}.*
%{_datadir}/applications/%{name}.desktop
%{_datadir}/metainfo/%{name}.appdata.xml
%config(noreplace) %{_sysconfdir}/default/%{name}

%changelog
* Mon Jan 28 2019 Your Name <[email protected]> - 1.0-1
- Initial SPEC release.

Листинг проекта 2 с использованием фреймворка Qt, использующего для сборки cmake и лицензированного под множественной лицензией:

Name: foo-bar
Version: 1.0
Release: 1%{?dist}

# Main code - GPLv3+;
# Logger module - MIT
# Icon - CC-BY-SA
License: GPLv3+ and MIT and CC-BY-SA
Summary: Example application

URL: https://github.com/example/%{name}
Source0: %{url}/archive/v%{version}.tar.gz#/%{name}-%{version}.tar.gz
Patch0: %{name}-fix-gcc90.patch

BuildRequires: cmake(Qt5LinguistTools)
BuildRequires: cmake(Qt5Multimedia)
BuildRequires: cmake(Qt5X11Extras)
BuildRequires: cmake(Qt5Network)
BuildRequires: cmake(Qt5Core)
BuildRequires: cmake(Qt5DBus)
BuildRequires: cmake(Qt5Gui)

BuildRequires: desktop-file-utils
BuildRequires: libappstream-glib
BuildRequires: gcc-c++
BuildRequires: cmake
BuildRequires: ninja
BuildRequires: gcc

%description
Full description of our example application.

%prep
%autosetup -p1
mkdir -p %{_target_platform}

%build
pushd %{_target_platform}
    %cmake -G Ninja \
    -DFOO=ON \
    -DBAR=OFF \
    ..
popd
%ninja_build -C %{_target_platform}

%install
%ninja_install -C %{_target_platform}
%find_lang %{name} --with-qt

%check
appstream-util validate-relax --nonet "%{buildroot}%{_datadir}/metainfo/%{name}.appdata.xml"
desktop-file-validate %{buildroot}%{_datadir}/applications/%{name}.desktop

%files -f %{name}.lang
%doc README.md
%license LICENSE
%{_bindir}/%{name}
%{_mandir}/man1/%{name}.*
%{_datadir}/applications/%{name}.desktop
%{_datadir}/metainfo/%{name}.appdata.xml

%changelog
* Mon Jan 28 2019 Your Name <[email protected]> - 1.0-1
- Initial SPEC release.

Листинг проекта 3 — динамической библиотеки с использованием Cmake и созданием дополнительных пакетов для заголовочных файлов и запуском юнит-тестов:

Name: foo-bar
Version: 1.0
Release: 1%{?dist}

License: GPLv3+
Summary: Example shared library

URL: https://github.com/example/%{name}
Source0: %{url}/archive/v%{version}.tar.gz#/%{name}-%{version}.tar.gz

BuildRequires: gcc-c++
BuildRequires: cmake
BuildRequires: ninja
BuildRequires: gcc

%description
Full description of our shared library.

%package devel
Summary: Development files for %{name}
Requires: %{name}%{?_isa} = %{?epoch:%{epoch}:}%{version}-%{release}

%description devel
%{summary}.

%prep
%autosetup -p1
mkdir -p %{_target_platform}

%build
pushd %{_target_platform}
    %cmake -G Ninja \
    -DBUILD_TESTS=ON \
    ..
popd
%ninja_build -C %{_target_platform}

%install
%ninja_install -C %{_target_platform}

%check
pushd %{_target_platform}
    ctest --output-on-failure
popd

%files
%doc README.md
%license LICENSE
%{_libdir}/lib%{name}.so.0*

%files devel
%{_includedir}/%{name}
%{_libdir}/lib%{name}.so
%{_libdir}/cmake/%{name}
%{_libdir}/pkgconfig/%{name}.pc

%changelog
* Mon Jan 28 2019 Your Name <[email protected]> - 1.0-1
- Initial SPEC release.

Литература

При написании статьи использовалась литература из следующих источников:

Пока нет комментариев.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *