Skip to content

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-devel

Requires - Зависимости исполнения.

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

В этих ситуациях мейнтейнеру, человеку собирающему пакет, необходимо прописать эти зависимости в 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 важно! Иначе не пропустит проверка Сизиф

Авторы

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