Spec
*.spec - текстовый файл содержащий информацию о названии, версии пакета, другую служебную информацию и инструкцию по сборке и установке пакета, а также информацию об изменениях изменений
Автоматическое создание .spec и .rules
Для автоматического создания файлов используется пакет github2spec
# apt-get install github2specТакже дополнительно устанавливаем необходимые для работы дополнительные пакеты
# apt-get install gear gear-restore-tags gear-remotes-utils gear-sh-functions gear-uupdateПосле чего вносим правки в файл конфигурации
~/.rpmmacrosДалее выполняем команду, которая сделает клонирование репозитория* и создаст необходимые файлы.
$ github2spec -u ССЫЛКА_НА_GITHUBИнформация
Стоит обратить внимание, что данный пакет не сделает полностью рабочий spec-файл (хотя может), но поможет в его создании.
Также стоит обратить внимание, что иногда может не сработать:
- клонирование репозитория;
- не создастся файл rules
В любом случае данный инструмент упростит жизнь, но не сделает её идеальной, нужно проверять вручную.
Структура Spec файла
Формально, spec файл можно разделить на несколько блоков (сугубо личное мнение)
Верхний блок
В данном блоке объявляются переменные, а также описываются включение/выключение подпакетов
Для объявления переменных используется %define
%define pypi_name dodoгде переменная %pypi_name = dodo
Как уже видно, используется переменная также с знаком %
Включение/выключение подпакетов также через %def_
К примеру ситуацию со сборкой в командной строке rpm --enable=static в spec файле можно описать так
%def_enable staticНаименования пакета
Блок содержит в себе имя, версию и релиз пакета, фактически из этого блока формируется имя пакета
Name: python3-module-%pypi_name
Version: 0.13.4
Release: alt1Где:
Name = имя пакета
Version = версия
Release = релиз по классификации Альта.
На выходе мы будем иметь пакет python3-module-dodo-0.13.4.alt1-архитектура.rpm
Где архитектура может быть x86_64, ppc64le, i586, aarch64
Также по мимо пакетов, собирается ещё пакет исходник python3-module-dodo-0.13.4-alt1.src.rpm
Разберём более детально пункт Release.
Данный пункт целиком зависит от пункта Version, то есть его нумерация будет идти напрямую от версии. В случае изменения версии релиз уйдёт на 1.
Увеличение версии релиза зависит от внесения мейнтейнером правок в пакет, в случае его повторной пересборки.
0.13.4 = alt1 > Первая сборка
найден баг, внесены изменения, пересобирается
0.13.4 = alt2 > Сборка с правками
выход новой версии пакета
0.13.5 = alt1 > первая сборка новой версии пакетаСлужебная информация (назовём её так)
В данном блоке находится информации о лицензии пакета, группе по классификации Альт и ссылка на источник
License: LGPL-3.0
Group: Development/Python3
URL: https://dodo.org/dodo/dodo.gitГде:
License - лицензия пакета по которому он создаётся.
Обычно описывается на странице исходника, так называемого upstream.
Для того, что бы не ошибиться в указании лицензии, рекомендую использовать утилиту для автоматического нахождения лицензий в исходниках.
Авто проверка всех лицензий
Для проверки всех лицензий в исходном коде используется утилита nomossa
nomossa -d КАТАЛОГ_GITГде КАТАЛОГ_GIT = каталог полученный с помощью git clone
Group - группа по классификации Альт, принадлежность пакета, так сказать.
Определении группы
Все группы описаны в файле GROUPS и для просмотра достаточно воспользоваться командой cat
$ cat /usr/lib/rpm/GROUPSКраткое описание
В данный блок можно отнести две позиции: само краткое описание и информацию о том, кто упаковал
Summary: python3 dodo
Packager: user <user@altlinux.org>Где:
Summary - краткое описание пакета, желательно указывать на английском
Packager - фамилия, имя и адрес электронной почты мейнтейнера, данный пункт spec файла необязателен к добавлению
Зависимости, архитектура и источник
Существуют два вида зависимостей
Сборочные зависимости - BuildRequires
Зависимости для выполнения - Requires
BuildRequires - это зависимости которые требуются для сборки пакетов, такие как компиляторы и другие сборочные зависимости без которых пакет не будет собран.
Также при необходимости наличия в окружении, где собирается пакет исходник *.src.rpm, дополнительных пакетов с макросами вида rpm-macros-*, либо rpm-build-* то их необходимо указывать в блоке BuildRequires(pre)
То есть к примеру
BuildRequires(pre): rpm-build-python3
BuildRequires: python3-develRequires - Зависимости исполнения.
Когда пакет успешно собран, он может установиться, но из-за того, что возможно не будет хватать каких-то пакетов для его нормальной работы, он будет либо крашиться, либо вообще не запускаться.
В этих ситуациях мейнтейнеру, человеку собирающему пакет, необходимо прописать эти зависимости в Requires . Обычно их пишут до зависимостей сборки, но не принципиально.
К примеру:
Requires: ffplayЕсли пакету не принципиально какая архитектура, к примеру он написан на python, то есть он интерпретируется на любой архитектуре, то надо обязательно установить данный параметр. В противном случае указывать его ненужно.
BuildArch: noarchГде noarch = отсутствие архитектуры и в таком случае пакет будет выглядеть так python3-module-dodo-0.13.4-alt1.noarch.rpm
Source - Источник. Перед сборкой пакета, согласно правилам rules, создаются архивы формата tar со сжатым исходным кодом. Актуально при локальной сборке по средствам хешер из склонированного git-репозитория.
К примеру
Source: %name-%version.tarГде:
%name = значению Name нашего же спека %version = значению Version нашего же спека
В случае использования нескольких источников сборки Source идёт со значением N+1
К примеру:
Source0: %name-%version.tar
Source1: vendor.tar
Source2: troll-cargo.tar
либо
Source: %name-%version.tar
Source1: vendor.tar
Source2: troll-cargo.tarИнформация
На лично мой взгляд, при локальной сборке, использовании конструкции %name-%version.tar является признаком хорошего тона и обязательно к исполнению.
Основная (директивная часть) часть
%description
Данный блок содержит полное описание назначения пакета. Предпочтительно указывать на английском
К примеру
%description
This is good%prep
Данный блок содержит перечень команд для подготовки к сборке, к примеру туже распаковку нашего источника.
Также в данном блоке могут содержаться сценарии shell необходимые для корректной сборки пакета.
к примеру:
%prep
%setup
либо
%prep
%setup
mkdir .cargo
tar -xf troll-cargo.tar -C troll
и так далее%build
Блок для сборки (компиляции или интерпретации) исходного кода.
К примеру при использовании meson вполне достаточно
%build
%meson
%meson_build%install
Блок который эмулирует установку в файловую систему.
К примеру при использовании meson вполне достаточно
%install
%meson_install%check
Блок команд для тестирования выходного пакета. Обычно включает в себя заранее заложенные тесты.
К примеру при использовании meson вполне достаточно
%check
%__meson_test%files
Список файлов, который будет установлен в конечную систему.
Информация
Для получения корректного перечня конечных файлов, рекомендую заменить блок команд в разделе install, дабы не собрать кривой пакет, который может успешно собраться, а может не собраться из-за путей
К примеру блок может выглядеть так
%_bindir/%name
%_datadir/applications/%_name.desktop
%_datadir/dbus-1/services/%_name.service
%_datadir/glib-2.0/schemas/%_name.gschema.xml
%doc README*В случае удачной компиляции и установки файлы путей эмулируются в каталог хешера по пути
~/hasher/chroot/usr/src/tmpТут Вы можете посмотреть что куда и правильно прописать блок %files
%changelog
ВАЖНЫЙ блок, содержащий записи изменений между различными сборками или версиями. Содержит информацию о дате сборки, информацию о мейнтейнере, версию и релиз пакета, а также список изменений.
К примеру
%changelog
* Mon Jun 03 2024 user <user@altlinux.org> 0.13.4-alt1
- Initial build for Sisyphus
либо
%changelog
* Mon Jun 04 2024 user <user@altlinux.org> 0.13.4-alt2
- yps :)
* Mon Jun 03 2024 user <user@altlinux.org> 0.13.4-alt1
- Initial build for SisyphusИнформация
Обращаю внимание, что это 0.13.4-alt1 важно! Иначе не пропустит проверка Сизиф
Давид Султаниязов
Александр Шамараев