Руководство по сборке RPM пакетов

Вступление

Руководство по упаковке RPM пакетов:

PDF Версия

Вы также можете скачать Руководство по сборке RPM пакетов.pdf

Файловая структура

Перед тем, как приступить к сборке, нужно создать структуру каталогов, необходимую RPM, находящуюся в Вашем «домашнем» каталоге:

Вклад в руководство

Вы можете внести свой вклад в это руководство, отправив сообщение о проблеме или запрос на извлечение на GitHub репозиторий.

Обе формы вклада высоко ценятся и приветствуются.

Не стесняйтесь подавать заявку на решение проблемы с обратной связью, отправлять запрос на извлечение на GitHub или и то, и другое!

Необходимые пакеты

Чтобы следовать этому руководству, Вам понадобятся пакеты, упомянутые ниже.

В Fedora, CentOS 8, и RHEL 8:

$ dnf install gcc rpm-build rpm-devel rpmlint make python bash coreutils diffutils patch rpmdevtools

В CentOS 7 и RHEL 7:

$ yum install gcc rpm-build rpm-devel rpmlint make python bash coreutils diffutils patch rpmdevtools

Зачем упаковывать программное обеспечение с помощью RPM?

Менеджер пакетов RPM (RPM) - это система управления пакетами, которая работает на Red Hat Enterprise Linux, CentOS и Fedora. RPM упрощает распространение, управление и обновление программного обеспечения, создаваемого для Red Hat Enterprise Linux, CentOS и Fedora. Многие поставщики программного обеспечения распространяют своё программное обеспечение через обычный архив (например, tarball). Однако, упаковка программного обеспечения в пакеты RPM имеет ряд преимуществ. Эти преимущества описаны ниже.

С помощью RPM Вы можете:

Ваш Первый пакет RPM

Создание пакета RPM может быть сложным. Вот полный рабочий файл спецификации RPM, в котором несколько вещей пропущены и упрощены.

Name:       hello-world
Version:    1
Release:    1
Summary:    Most simple RPM package
License:    FIXME

%description
This is my first RPM package, which does nothing.

%prep
# we have no source, so nothing here

%build
cat > hello-world.sh <<EOF
#!/usr/bin/bash
echo Hello world
EOF

%install
mkdir -p %{buildroot}/usr/bin/
install -m 755 hello-world.sh %{buildroot}/usr/bin/hello-world.sh

%files
/usr/bin/hello-world.sh

%changelog
# let's skip this for now

Сохраните этот файл как hello-world.spec.

Теперь используйте эти команды:

$ rpmdev-setuptree
$ rpmbuild -ba hello-world.spec

Команда rpmdev-setuptree создает несколько рабочих каталогов. Поскольку эти каталоги постоянно хранятся в $HOME, эту команду не нужно использовать снова.

Команда rpmbuild создает фактический пакет rpm. Вывод этой команды может быть похож на:

... [SNIP]
Wrote: /home/mirek/rpmbuild/SRPMS/hello-world-1-1.src.rpm
Wrote: /home/mirek/rpmbuild/RPMS/x86_64/hello-world-1-1.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.wgaJzv
+ umask 022
+ cd /home/mirek/rpmbuild/BUILD
+ /usr/bin/rm -rf /home/mirek/rpmbuild/BUILDROOT/hello-world-1-1.x86_64
+ exit 0

Файл /home/mirek/rpmbuild/RPMS/x86_64/hello-world-1-1.x86_64.rpm является Вашим первым пакетом RPM. Его можно установить в систему и протестировать.

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

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

Что такое Исходный код?

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

В этом руководстве представлены три версии программы Hello World , каждая из которых написана на разных языках программирования. Программы, написанные на этих трех разных языках, упаковываются по разному и охватывают три основных варианта использования RPM упаковщиком ПО.

Программа Hello World, написанная на bash:

bello

#!/bin/bash

printf "Hello World\n"

Hello World, написанная на Python:

pello.py

#!/usr/bin/env python

print("Hello World")

Hello World, написанная на C :

cello.c

#include <stdio.h>

int main(void) {
    printf("Hello World\n");
    return 0;
}

Целью каждой из трех программ является вывод строки Hello World в командной строке.

Как создаются программы

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

Изначально скомпилированный код

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

Пакеты RPM, созданные таким образом, зависят от архитектуры Это означает, что если вы скомпилируете такое программное обеспечение на компьютере, использующем 64-разрядный (x86_64) процессор AMD или Intel, оно не будет выполняться на 32-разрядном (x86) процессоре AMD или Intel. В названии результирующего пакета будет указана архитектура.

Интерпретируемый код

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

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

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

Программы с прямой интерпретацией

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

Программы, скомпилированные в байт-код

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

Сборка программного обеспечения из исходного кода

В этом разделе объясняется сборка программного обеспечения на основе его исходного кода.

Изначально скомпилированный код

В этом примере вы создадите cello.c программу, написанную на языке C в исполняемый файл.

cello.c

#include <stdio.h>

int main(void) {
    printf("Hello World\n");
    return 0;
}

Ручная сборка

Вызовите компилятор C из коллекции компиляторов GNU (GCC) чтобы скомпилировать исходный код в бинарный файл:

gcc -g -o cello cello.c

Запустите бинарный файл cello.

$ ./cello
Hello World

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

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

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

Чтобы настроить автоматическую сборку, создайте файл с именем Makefile в том же каталоге, что иcello.c:

Makefile

cello:
        gcc -g -o cello cello.c

clean:
        rm cello

Теперь, чтобы собрать программу, просто запустите make:

$ make
make: 'cello' is up to date.

Посколько сборка уже создана, make clean очистит её, а затем снова запустит make:

$ make clean
rm cello

$ make
gcc -g -o cello cello.c

Опять же, попытка сборки после другой сборки ничего не даст:

$ make
make: 'cello' is up to date.

Наконец, программа выполнится:

$ ./cello
Hello World

Теперь Вы скомпилировали программу как вручную, так и с помощью инструмента сборки.

Интерпретируемый код

Следующие два примера демонстрируют компиляцию в байт-код программы, написанной на Python и прямую интерпретацию программы, написанной на bash.

Компиляция байт-кода

В этом примере Вы скомпилируете в байт-код pello.py - программу, написанную на Python, который затем выполняется виртуальной машиной Python. Исходный код Python также может быть напрямую интерпретирован, но исполнение байт-кода быстрее. Следовательно, RPM упаковщики предпочитают упаковывать скомпилированный байт-код для распространения среди конечных пользователей.

pello.py

#!/usr/bin/env python

print("Hello World")

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

Компиляция pello.py в байт-код:

$ python -m compileall pello.py

$ file pello.pyc
pello.pyc: python 2.7 byte-compiled

Выполните байт-код в pello.pyc:

$ python pello.pyc
Hello World

Напрямую интепретированный код

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

bello

#!/bin/bash

printf "Hello World\n"

Для программ, написанных на языках сценариев оболочки, таких как bash, используется прямая интерпретация. Следовательно, Вам нужно только сделать файл с исходным кодом исполняемым и запустить его:

$ chmod +x bello
$ ./bello
Hello World

Программное обеспечение для исправления ошибок

Patch - это исходный код, который исправляет другой исходный код. Он отформатирован как diff, потому что представляет разницу между двумя версиями текста. Разница создаётся с помощью утилиты diff, которая затем применяется к исходному коду с помощью утилиты patch.

В следующем примере мы создаем исправление из исходного кода с помощью diff, а затем используем patch. Исправление использует в следующих разделах при создании RPM и работе со .spec-файлом. Работа со SPEC файлами.

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

Чтобы создать патч для cello.c:

Чтобы исправить cello.c с помощью cello-output-first-patch.patch, перенаправьте патч-файл patch коммандой:

$ patch < cello-output-first-patch.patch
patching file cello.c

Содержимое cello.c теперь отражает изменения:

$ cat cello.c
#include<stdio.h>

int main(void){
    printf("Hello World from my very first patch!\n");
    return 0;
}

Чтобы собрать и запустить отредактированную cello.c:

$ make clean
rm cello

$ make
gcc -g -o cello cello.c

$ ./cello
Hello World from my very first patch!

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

Установка Произвольных Артефактов

Большим преимуществом Linux и других Unix-подобных систем является Стандарт иерархии файловой системы . Он указывает, в каком каталоге должны быть расположены файлы. Файлы, установленные из пакетов RPM, должны быть размещены в соответствии с ИФС. Например, исполняемый файл должен находиться в каталоге, который находится в переменной PATH .

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

Мы рассмотрим два популярных способа размещения произвольных артефактов в системе: с помощью команды install и с помощью команды make install.

Использование команды install

Иногда с помощью инструментов автоматизации сборки, таких как GNU make не является оптимальным - например, если упакованная программа проста. В этих случаях упаковщики часто используют команду install (предоставляемая системе coreutils), которая помещает артефакт в указанный каталог в файловой системе с указанным набором разрешений.

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

В этом примере install помещает файл bello в /usr/bin с разрешениями, общими для исполняемых скриптов:

$ sudo install -m 0755 bello /usr/bin/bello

Теперьbello находится в каталоге, который указан в переменной $PATH . Таким образом, Вы можете запустить bello из любого каталога, не указывая его путь:

$ cd ~

$ bello
Hello World

Использование команды make install

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

Добавьте секцию install в Makefile:

Makefile

cello:
        gcc -g -o cello cello.c

clean:
        rm cello

install:
        mkdir -p $(DESTDIR)/usr/bin
        install -m 0755 cello $(DESTDIR)/usr/bin/cello

Переменная $(DESTDIR) является встроенной в GNU make и обычно используется для указания установки в каталог, отличный от корневого каталога.

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

Для сборки и установки программы cello.c:

$ make
gcc -g -o cello cello.c

$ sudo make install
install -m 0755 cello /usr/bin/cello

Теперьcello находится в каталоге, который указан в переменной $PATH . Таким образом, Вы можете запустить cello из любого каталога, не указывая его полный путь.

$ cd ~

$ cello
Hello World

Вы установили артефакт сборки в выбранное место в системе.

Подготовка исходного кода для упаковки

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

Программное обеспечение должно распространяться с лицензией . Для примера мы будем использовать лицензию GPLv3. Текст лицензии помещается в файл LICENSE для каждой из примеров программ. Упаковщику RPM необходимо иметь дело с файлами лицензий при упаковке.

Для использования со следующими примерами создайте файл LICENSE:

$ cat /tmp/LICENSE
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.

Создание Tarball с исходным кодом

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

bello

Проект bello реализует Hello World в bash. Реализация содержит только сценарий оболочки bello, поэтому результирующий архив tar.gz будет содержать только один файл, кроме файла LICENSE. Давайте предположим, что это версия программы - 0.1

Подготовьте проект bello для распространения:

pello

Проект pello реализует Hello World на Python. Реализация содержит только программу pello.py, так что результирующий архив tar.gz будет содержать только один файл, кроме файла LICENSE. Предположим, что это версия программы - 0.1.1

Подготовьте проект pello для распространения:

cello

Проект cello реализует Hello World на C . Реализация содержит только файлы cello.c и Makefile, поэтому результирующий архив tar.gz будет содержать только два файла, помимо файла LICENSE. Давайте предположим, что это версия программы - 1.0

Обратите внимание, что patch не распространяется в архиве вместе с программой. Упаковщик RPM применяет исправление при создании RPM. Патч будет помещен в каталог ~/rpmbuild/SOURCES/ рядом с .tar.gz архивом.

Подготовьте проект cello для распространения:

Теперь исходный код готов к упаковке в RPM.

Программное обеспечение для упаковки

В этом руководстве объясняется, как упаковывать RPM для дистрибутивов Linux семейства Red Hat, в первую очередь:

Эти дистрибутивы используют формат упаковки RPM.

Хотя эти дистрибутивы являются целевой средой, данное руководство в основном применимо ко всем дистрибутивам, основанным на RPM based . Однако инструкции должны быть адаптированы для функций, специфичных для дистрибутива, таких как обязательные элементы установки, рекомендации или макросы.

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

RPM Пакеты

В этом разделе рассматриваются основы формата упаковки RPM. Дополнительные сведения смотри в разделе Дополнительные материалы.

Что такое RPM?

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

Существует два типа пакетов RPM:

SRPMs и бинарные RPMs имеют общий формат файла и инструментарий, но имеют разное содержимое и служат разным целям. SRPM содержит исходный код, при необходимости исправления к нему и файл спецификации, в котором описывается, как встроить исходный код в бинарный RPM. Бинарный RPM содержит двоичные файлы, созданные из исходных текстов и патчей.

Инструменты для упаковки RPM

Пакетrpmdevtools, установленный на этапе Необходимые пакеты, предоставляет несколько утилит для упаковки RPM. Чтобы перечислить эти утилиты, запустите:

$ rpm -ql rpmdevtools | grep bin

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

Рабочее пространство для упаковки RPM

Чтобы настроить макет каталога, который является рабочей областью упаковки RPM, используйте утилиту rpmdev-setuptree:

$ rpmdev-setuptree

$ tree ~/rpmbuild/
/home/user/rpmbuild/
|-- BUILD
|-- RPMS
|-- SOURCES
|-- SPECS
`-- SRPMS`

5 directories, 0 files

Созданные каталоги служат следующим целям:

Что такое SPEC файл?

Файл спецификации можно рассматривать как "рецепт", который утилита rpmbuild использует для фактической сборки RPM. Он сообщает системе сборки, что делать, определяя инструкции в серии разделов. Разделы определены в Преамбуле и в Основной части. Преамбула содержит ряд элементов метаданных, которые используются в Основной части. Тело содержит основную часть инструкций.

Пункты преамбулы

В этой таблице перечислены элементы, используемые в разделе преамбулы файла спецификации RPM:

Директивы Name, Version и Release содержат имя файла пакета RPM. Разработчики пакетов RPM и системные администраторы часто называют эти три директивы N-V-R или NVR, поскольку имена файлов пакетов RPM имеют формат NAME-VERSION-RELEASE.

Вы можете получить пример NAME-VERSION-RELEASE, выполнив запрос с использованием rpm для конкретного пакета:

$ rpm -q python
python-2.7.5-34.el7.x86_64

Здесь python - это имя пакета, 2.7.5 - версия, а 34.el7 - релиз. Последний маркер x86_64 - сведения об архитектуре. В отличие от NVR, маркер архитектуры не находится под прямым управлением RPM упаковщика, а определяется средой сборки rpmbuild. Исключением из этого правила является архитектурно-независимый пакет noarch.

Составляющие основной части

В этой таблице перечислены элементы, используемые в разделе Body (Тело, основная часть) файла спецификации RPM:

Дополнительные элементы

Файл спецификации также может содержать дополнительные элементы. Например, файл спецификации может содержать скриптлеты_ и триггеры__. Они вступают в силу в разные моменты процесса установки в системе конечного пользователя (не в процессе сборки).

Дополнительную информацию см. Триггеры и скриптлеты.

BuildRoots

В контексте упаковки RPM "buildroot" - это среда chroot Это означает, что артефакты сборки размещаются здесь с использованием той же иерархии файловой системы, что и в системе конечного пользователя, при этом "buildroot" выступает в качестве корневого каталога. Размещение артефактов сборки должно соответствовать стандарту иерархии файловой системы конечного пользователя.

Файлы в "buildroot" позже помещаются в архив cpio , который становится основной частью RPM. Когда RPM устанавливается в системе конечного пользователя, эти файлы извлекаются в корневой каталог, сохраняя правильную иерархию.

RPM Макросы

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

Это полезно, например, при многократной ссылке на Version упакованного программного обеспечения в файле спецификации. Вы определяете Version только один раз - в макросе %{version}. Затем используйте %{version} во всем файле спецификации. Каждый раз, во время определения строки %{version}, в конечном итоге будет подставлена Version программы, которую вы определили ранее.

$ rpm --eval %{_MACRO}

$ rpm --eval %{_bindir}
/usr/bin

$ rpm --eval %{_libexecdir}
/usr/libexec

Распространённым макросом является %{?dist}, который обозначает “тег распространения”. Он сигнализирует, какой дистрибутив используется для сборки.

Например:

# On a RHEL 7.x machine
$ rpm --eval %{?dist}
.el7

# On a Fedora 23 machine
$ rpm --eval %{?dist}
.fc23

Больше информации о макросах см. в разделе Подробнее о макросах.

Работа со SPEC файлами

Большая часть упаковки программного обеспечения в RPMs - это редактирование файла спецификации. В этом разделе мы обсудим, как создать и изменить SPEC файл.

Чтобы упаковать новое программное обеспечение, Вам необходимо создать новый файл спецификации. Вместо того, чтобы писать его вручную с нуля, используйте утилиту rpmdev-newspec. Она создаёт незаполненный файл спецификации, и Вы заполняете необходимые директивы и поля.

В этом руководстве мы используем три примера реализации программы 'Hello World!', созданной при подготовке программного обеспечения для упаковки:

Переместите их в ~/rpmbuild/SOURCES.

Создайте SPEC файл для каждой из трёх программ:

$ cd ~/rpmbuild/SPECS

$ rpmdev-newspec bello
bello.spec created; type minimal, rpm version >= 4.11.

$ rpmdev-newspec cello
cello.spec created; type minimal, rpm version >= 4.11.

$ rpmdev-newspec pello
pello.spec created; type minimal, rpm version >= 4.11.

~/rpmbuild/SPECS/ каталог теперь имеет три SPEC файла с именами bello.spec, cello.spec, и pello.spec.

Изучите файлы. Директивы в них представляют собой директивы, описанные в разделе Что такое SPEC файл. В следующих разделах Вы заполните эти файлы спецификаций.

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

bello

Первый SPEC файл создан для bash скрипта bello из раздела Подготовка программного обеспечения для упаковки.

Убедитесь, что у вас есть:

Теперь измените ~/rpmbuild/SPECS/bello.spec для создания RPMs пакета bello:

Вы написали целый файл спецификации bello. Послный SPEC файл bello теперь выглядит так:

Name:           bello
Version:        0.1
Release:        1%{?dist}
Summary:        Hello World example implemented in bash script

License:        GPLv3+
URL:            https://www.example.com/%{name}
Source0:        https://www.example.com/%{name}/releases/%{name}-%{version}.tar.gz

Requires:       bash

BuildArch:      noarch

%description
The long-tail description for our Hello World Example implemented in
bash script.

%prep
%setup -q

%build

%install

mkdir -p %{buildroot}/%{_bindir}

install -m 0755 %{name} %{buildroot}/%{_bindir}/%{name}

%files
%license LICENSE
%{_bindir}/%{name}

%changelog
* Tue May 31 2016 Adam Miller <maxamillion@fedoraproject.org> - 0.1-1
- First bello package
- Example second item in the changelog for version-release 0.1-1

В следующем разделе рассказывается о том, как собрать RPM.

pello

Наш второй SPEC будет для примера, написанного на языке программирования Python, который Вы скачали (или создали имитированный upstream- выпуск в разделе Подготовка программного обеспечения) и разместили его исходный код в ~/rpmbuild/SOURCES/. Давайте продолжим и откроем файл ~/rpmbuild/SPECS/pello.spec, и начнём заполнять некоторые поля.

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

Мы создадим небольшой сценарий оболочки для вызова нашего байт-скомпилированного кода, который станет точкой входа в наше программное обеспечение. Мы сделаем это как часть самого нашего файла спецификации, чтобы продемонстрировать, как вы можете создавать сценарии действий внутри SPEC файла. Мы рассмотрим эти особенности позже в разделе %install.

Давайте продолжим и откроем файл ~/rpmbuild/SPECS/pello.spec и начнем заполнять некоторые поля.

Ниже приведен шаблон вывода, который мы получили изrpmdev-newspec.

Name:           pello
Version:
Release:        1%{?dist}
Summary:

License:
URL:
Source0:

BuildRequires:
Requires:

%description

%prep
%setup -q

%build
%configure
make %{?_smp_mflags}

%install
rm -rf $RPM_BUILD_ROOT
%make_install

%files
%doc

%changelog
* Tue May 31 2016 Adam Miller <maxamillion@fedoraproject.org>
-

Как и в первом примере, давайте начнем с первого набора директив, которые rpmdev-newspecсгруппировал в верхней части файла: Name, Version, Release, Summary. Поле Name уже заполнено, так как мы передали его в командной строке при использовании команды rpmdev-newspec.

Давайте установим Version соответствующую версии “upstream” релиза исходного кода pello , которая, как мы видим, равна 0.1.1, как указано в примире кода, который мы загрузили (или создали в разделе Подготовка программного обеспечения section).

В поле Release уже установлено значение 1%{?dist} которое изначально равно 1, и должно увеличиваться каждый раз, когда пакет обнавляется по какой-либо причине, например, включает новый патч для устранения проблемы, но не имеет новой версии upstream-выпуска. Когда происходит новый upstream-выпуск (например, была выпущена версия pello 0.1.2) тогда Release должен быть сброшен до значения 1. disttag%{?dist} выглядит знакоммо по описанию макросов из RPM Макросы в предыдущем разделе.

Поле Summary должно представлять собой краткое, в одну строку, объяснение того, что представляет собой это программное обеспечение.

После Ваших изменений первый раздел SPEC файла примет следующий вид:

Name:           pello
Version:        0.1.1
Release:        1%{?dist}
Summary:        Hello World example implemented in Python

Теперь давайте перейдем ко второму набору директив, которые rpmdev-newspec сгруппировал вместе в нашем SPEC файле: License, URL, Source0.

Поле License - это Лицензия на программное обеспечение , связанная с исходным кодом из upstream выпуска. Точный формат обозначения лицензии в вашем файле SPEC будет варьироваться в зависимости от того, каким конкретным рекомендациям по дистрибутиву Linux, использующему RPM, Вы следуете. Мы будем использовать стандарты обозначения из Fedora Руководство по лицензированию, поэтому это поле будет содержать лицензию GPLv3+

Поле URL - это веб-сайт upstream программного обеспечения. Это не ссылка на скачивание исходного кода, а фактический веб-сайт проекта, продукта или компании, где кто-то может найти больше информации о конкретной части программного обеспечения. Поскольку это просто пример, мы будем использовать адрес https://example.com/pello. Однако, мы применим макрос RPM %{name} для корректности оформления.

Поле Source0 - это место, откуда должен быть загружен upstream исходный код программного обеспечения. Этот URL-адрес должен содержать прямую ссылку на конкретную версию выпуска исходного кода, которую мы упаковываем. Еще раз, поскольку это пример, мы будем использовать ссылку на следующий архив: https://example.com/pello/releases/pello-0.1.1.tar.gz.

Мы должны отметить, что в этом примере URL-адреса есть жёстко закодированные значения, которые можно изменить в будущем, и потенциально они даже могут измениться, например, версия выпуска 0.1.1. Мы можем упростить это, если потребуется обновить только одно поле в SPEC файле и разрешить его повторное использование. Мы будем использовать макросы https://example.com/%{name}/releases/%{name}-%{version}.tar.gz вместо ссылок из примеров раннее.

После ваших изменений верхняя часть Вашего SPEC файла должна выглядеть следующим образом:

Name:           pello
Version:        0.1.1
Release:        1%{?dist}
Summary:        Hello World example implemented in Python

License:        GPLv3+
URL:            https://example.com/%{name}
Source0:        https://example.com/%{name}/release/%{name}-%{version}.tar.gz

У нас есть секции BuildRequires и Requires, каждая из которых определяет что-то, что требуется для пакета. Однако , BuildRequires должен сообщать rpmbuild о том, что необходимо Вашему пакету во время сборки, аRequires - это то, что необходимо Вашему пакету во время установки.

В этом примере нам понадобится пакет python для выполнения процесса сборки с компиляцией в байт-код. Этот пакет понадобится во время выполнения скомпилированного байт-кода, поэтому нам необходимо определить python как требуемый пакет в директиве Requires. Нам также понадобится пакет bash для выполнения небольшого сценария точки входа, который мы будем использовать здесь.

Поскольку эта программа написана на интерпритируемом языке программирования без изначально скомпилированных расширений, нужно добавить секцию ``BuildArch``. В ней задано значение noarch, чтобы сообщить RPM, что этот пакет не нужно привязывать к архитектуре процессора, на которой он построен.

После Ваших изменений верхняя часть Вашего SPEC файла должна выглядеть следующим образом:

Name:           pello
Version:        0.1.1
Release:        1%{?dist}
Summary:        Hello World example implemented in Python

License:        GPLv3+
URL:            https://example.com/%{name}
Source0:        https://example.com/%{name}/release/%{name}-%{version}.tar.gz

BuildRequires:  python
Requires:       python
Requires:       bash

BuildArch:      noarch

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

Секция %description - это более длинное и полное описание программного обеспечения, чем Summary, содержащее один или несколько абзацев. В нашем примере мы будем использовать только краткое описание. Эта секция не будет содержать глубокое описание, но при желании раздел может быть целым абзацем или более.

Секция %prep - это место, где мы подготавливаем нашу среду сборки или рабочее пространство для сборки. Чаще всего здесь происходит расширение сжатых архивов исходного кода, применение исправлений и, возможно, анализ информации, предоставленной в исходном коде, которая необходима в следующей части SPEC файла. В этом разделе мы просто будем использовать предоставленный макрос %setup -q.

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

Секция %build нашего SPEC файла должна выглядеть следующим образом:

%build

python -m compileall pello.py

Секция %install - это раздел, отвечающий за инструктирование rpmbuild, устанавливающее наше ранее созданное программное обеспечение в BUILDROOT, который фактически является базовым каталогом chroot , в котором ничего нет, и нам нужно будет создать любые пути или иерархии каталогов, которые нам понадобятся, чтобы установить наше программное обеспечение в определенных местах. Однако наши макросы RPM помогают нам выполнить эту задачу без необходимости жестко кодировать пути.

Ранее мы обсуждали, что, поскольку мы потеряем контекст файла со строкой shebang в нём при компиляции в байт-код, нам нужно будет создать простой сценарий-оболочку для выполнения этой задачи. Есть много вариантов того, как это сделать, включая, но не ограничиваясь этим, создание отдельного скрипта и использование его в качестве отдельной директивы SourceX, а также вариант, который мы собираемся показать в этом примере, который заключается в сборке файла в строке в SPEC файле. Причина, по которой мы показываем примерный вариант, заключается в том, чтобы просто продемонстрировать, что сам файл спецификации доступен для сценариев. Мы собираемся создать небольшой “сценарий-оболочку”, который будет выполнять скомпилированный байт-код Python, используя here document . Нам также нужно будет установить скомпилированный байт-код в каталог библиотеки в системе, чтобы к нему можно было получить доступ.

Секция %install после Ваших изменений должна выглядеть следующим образом:

%install

mkdir -p %{buildroot}/%{_bindir}
mkdir -p %{buildroot}/usr/lib/%{name}

cat > %{buildroot}/%{_bindir}/%{name} <<-EOF
#!/bin/bash
/usr/bin/python /usr/lib/%{name}/%{name}.pyc
EOF

chmod 0755 %{buildroot}/%{_bindir}/%{name}

install -m 0644 %{name}.py* %{buildroot}/usr/lib/%{name}/

Секция %files - это место, где мы предоставляем список файлов, которые предоставляет этот RPM и где они должны находиться в системе, на которую установлен RPM. Обратите внимание, что это относится не к %{buildroot}, а к полному пути к файлам, поскольку ожидается, что они будут существовать в конечной системе после установки. Таким образом, список устанавливаемого файла pello будет: %{_bindir}/pello. Нам также нужно будет предоставить список %dir, чтобы определить, что этот пакет “владеет” каталогом библиотеки, который мы создали, а также всеми файлами, которые мы разместили в нём.

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

Секция %files после Ваших изменений должен выглядеть следующим образом:

%files
%license LICENSE
%dir /usr/lib/%{name}/
%{_bindir}/%{name}
/usr/lib/%{name}/%{name}.py*

Последняя секция, %changelog, представляет собой список записей с отметками о дате, которые соотносятся с конкретной версией-выпуском пакета. Это не журнал изменений в программном обеспечении от выпуска к выпуску, а конкретно изменения в упаковке. Например, если программное обеспечение в пакете нуждалось в исправлении или было необходимо внести изменения в процедуру сборки, указанную в секции%build, эта информация будет размещена здесь. Каждая запись изменения может содержать несколько элементов, и каждый элемент должен начинаться с новой строки и символа -. Ниже приведен наш пример записи:

%changelog
* Tue May 31 2016 Adam Miller <maxamillion@fedoraproject.org> - 0.1.1-1
- First pello package
- Example second item in the changelog for version-release 0.1.1-1

Обратите внимание на приведенный выше формат: отметка даты будет начинаться с символа *, за которым следует календарный день недели, месяц, день месяца, год, затем контактная информация для упаковщика RPM. Оттуда у нас есть символ- перед выпуском версии, что является часто используемым, но не строго регламентированным. Затем, наконец, Версия-Релиз.

Вот и все! Мы написали целый файл спецификаций для pello! В следующем разделе мы расскажем, как создать RPM!

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

Name:           pello
Version:        0.1.1
Release:        1%{?dist}
Summary:        Hello World example implemented in python

License:        GPLv3+
URL:            https://www.example.com/%{name}
Source0:        https://www.example.com/%{name}/releases/%{name}-%{version}.tar.gz

BuildRequires:  python
Requires:       python
Requires:       bash

BuildArch:      noarch

%description
The long-tail description for our Hello World Example implemented in
Python.

%prep
%setup -q

%build

python -m compileall %{name}.py

%install

mkdir -p %{buildroot}/%{_bindir}
mkdir -p %{buildroot}/usr/lib/%{name}

cat > %{buildroot}/%{_bindir}/%{name} <<-EOF
#!/bin/bash
/usr/bin/python /usr/lib/%{name}/%{name}.pyc
EOF

chmod 0755 %{buildroot}/%{_bindir}/%{name}

install -m 0644 %{name}.py* %{buildroot}/usr/lib/%{name}/

%files
%license LICENSE
%dir /usr/lib/%{name}/
%{_bindir}/%{name}
/usr/lib/%{name}/%{name}.py*

%changelog
* Tue May 31 2016 Adam Miller <maxamillion@fedoraproject.org> - 0.1.1-1
  - First pello package

cello

Наш третий SPEC файл будет для нашего примера на языке C , для которого мы ранее создали имитированную версию upstream (или вы скачали) и разместили его исходный код в ~/rpmbuild/SOURCES/.

Давайте откроем файл ~/rpmbuild/SPECS/cello.spec и начнём заполнять некоторые поля.

Ниже приведен шаблон вывода, который мы получили от rpmdev-newspec.

Name:           cello
Version:
Release:        1%{?dist}
Summary:

License:
URL:
Source0:

BuildRequires:
Requires:

%description

%prep
%setup -q

%build
%configure
make %{?_smp_mflags}

%install
rm -rf $RPM_BUILD_ROOT
%make_install

%files
%doc

%changelog
* Tue May 31 2016 Adam Miller <maxamillion@fedoraproject.org>
-

Как и в предыдущих примерах, давайте начнем с первого набора директив, которые rpmdev-newspec сгруппировал в верхней части файла: Name, Version, Release, Summary. The Name уже указано, потому что мы предоставили эту информацию в командной строке для rpmdev-newspec.

Давайте установим в поле Version значение, соответствующее “upstream” версии исходного кода cello, которая, как мы видим, равна 1.0, как указано в примере кода, который мы загрузили (или создали в секции Подготовка программного обеспечения).

В Release уже установлено значение 1%{?dist} числовое значение, которое изначально равно 1, должно увеличиваться каждый раз, когда пакет обновляется по какой-либо причине, например, включает новый патч для устранения проблемы, но не имеет новой версии upstream выпуска. Когда происходит новый upstream выпуск (например, была выпущена версия cello 2.0), тогда значение Release должно быть сброшено до1. disttag%{?dist} выглядит знакоммо по описанию макросов из RPM Макросы в предыдущем разделе.

Summary должно представлять собой краткое, в одну строку, объяснение того, что представляет собой это программное обеспечение.

После ваших изменений первый раздел SPEC файла должен выглядеть следующим образом:

Name:           cello
Version:        1.0
Release:        1%{?dist}
Summary:        Hello World example implemented in C

Теперь давайте перейдем ко второму набору директив, которые rpmdev-newspec сгруппировал вместе в нашем SPEC файле: License, URL, Source0. Однако, мы добавим одну директиву в эту группу, поскольку она тесно связана с Source0 , и это наш Patch0 в котором будет указан первый патч, который нам нужен для нашего программного обеспечения.

Поле License - это Лицензия на программное обеспечение, связанная с исходным кодом из upstream выпуска. Точный формат обозначения лицензии в вашем SPEC файле будет варьироваться в зависимости от того, каким конкретным рекомендациям по дистрибутиву Linux, использующим RPM, Вы следуете. Мы будем использовать стандарты обозначения из Fedora. Руководство по лицензированию, поэтому это поле будет содержать лицензию GPLv3+

Поле URL - это веб-сайт upstream программного обеспечения. Это не ссылка на скачивание исходного кода, а фактический веб-сайт проекта, продукта или компании, где кто-то может найти больше информации об этой конкретной части программного обеспечения. Поскольку это просто пример, мы будем использовать адрес. https://example.com/сello. Однако, мы применим макрос RPM %{name} для корректности оформления.

Поле Source0 - это место, откуда должен быть загружен upstream исходный код программного обеспечения. Этот URL-адрес должен содержать прямую ссылку на конкретную версию выпуска исходного кода, которую мы упаковываем. Еще раз, поскольку это пример, мы будем использовать ссылку на следующий архив: https://example.com/cello/releases/cello-1.0.tar.gz

Мы должны отметить, что в этом примере URL-адреса есть жестко закодированные значения, которые можно изменить в будущем и потенциально они даже могут измениться, например, версия выпуска 1.0. Мы можем упростить это, если потребуется обновить только одно поле в SPEC файле и разрешить его повторное использование. Мы будем использовать макросы https://example.com/%{name}/releases/%{name}-%{version}.tar.gz, вместо ссылок из примеров раннее.

Следующий пункт - предоставить список для файла .patch который мы создали ранее, чтобы мы могли применить его к коду позже в секции%prep. Нам понадобится список Patch0: cello-output-first-patch.patch.

После Ваших изменений верхняя часть SPEC файла должна выглядеть следующим образом:

Name:           cello
Version:        1.0
Release:        1%{?dist}
Summary:        Hello World example implemented in C

License:        GPLv3+
URL:            https://example.com/%{name}
Source0:        https://example.com/%{name}/release/%{name}-%{version}.tar.gz

Patch0:         cello-output-first-patch.patch

У нас есть секции BuildRequires и Requires, каждая из которых определяет что-то, что требуется для пакета. Однако, BuildRequires должен сообщать rpmbuild, что необходимо Вашему пакету во время сборки, аRequires - это то, что необходимо пакету во время установки.

В этом примере нам понадобятся пакеты gcc и make для выполнения процесса сборки и компиляции. Требования времени выполнения, к счастью, обрабатываются rpmbuild, потому что эта программа не требует ничего за пределами основных стандартных библиотек C , и поэтому нам не нужно будет определять что-либо вручную в качестве Requires , и мы можем опустить эту директиву.

После Ваших изменений верхняя часть SPEC Вашего файла должна выглядеть следующим образом:

Name:           cello
Version:        0.1
Release:        1%{?dist}
Summary:        Hello World example implemented in C

License:        GPLv3+
URL:            https://example.com/%{name}
Source0:        https://example.com/%{name}/release/%{name}-%{version}.tar.gz

BuildRequires:  gcc
BuildRequires:  make

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

Секция %description - это более длинное и полное описание программного обеспечения, чем Summary, содержащее один или несколько абзацев. В нашем примере мы будем использовать только краткое описание. В нашем примере это секция не будет содержать глубокое описание, но при желании этот раздел может быть целым абзацем и более.

Секция %prep - это место, где мы подготавливаем нашу среду сборки или рабочее пространство для сборки. Чаще всего здесь происходит расширение сжатых архивов исходного кода, применение исправлений и, возможно, анализ информации, предоставленной в исходном коде, которая необходима в следующей части SPEC файла. В этом разделе мы просто будем использовать предоставленный макрос %setup -q.

Секция %build это то, где мы рассказываем системе, как на самом деле собирать программное обеспечение, которое мы упаковываем. Поскольку мы написали простой Makefile для нашей реализации на C , мы можем просто использовать команду GNU make: rpmdev-newspec. Однако нам нужно удалить вызов, %configure, поскольку мы не предоставили configure script . Секция %build нашего SPEC файла должна выглядеть следующим образом.

%build
make %{?_smp_mflags}

Секция %install - это то, где мы инструктируем rpmbuild как установить наше программное обеспечение в BUILDROOT, который фактически является базовым каталогом chroot , в котором ничего нет, и нам нужно будет создать любые пути или иерархии каталогов, которые нам понадобятся, чтобы установить наше программное обеспечение. Однако наши макросы RPM помогают нам выполнить эту задачу без необходимости жестко кодировать пути.

Еще раз, поскольку у нас есть простой Makefile , шаг установки можно легко выполнить, оставив на месте макрос %make_install , который снова был предоставлен нам командой rpmdev-newspec.

Секция %install после Ваших изменений должна принять следующий вид:

%install
%make_install

Секция %files - это место, где мы предоставляем список файлов, которые предоставляет этот RPM, и где они должны находиться в системе. Обратите внимание, что это относится не к %{buildroot}, а к полному пути к файлам, поскольку ожидается, что они будут существовать в конечной системе после установки. Таким образом, путь устанавливаемого файла cello будет: %{_bindir}/cello.

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

Секция %files после Ваших изменений должна выглядеть следующим образом:

%files
%license LICENSE
%{_bindir}/%{name}

Последняя секция, %changelog, представляет собой список записей с отметками о дате, которые соотносятся с конкретной версией-выпуском пакета. Это не журнал изменений в программном обеспечении от выпуска к выпуску, а конкретно изменения в упаковке. Например, если программное обеспечение в пакете нуждалось в исправлении или было необходимо внести изменения в процедуру сборки, указанную в секции%build, эта информация будет размещена здесь. Каждая запись изменения может содержать несколько элементов, и каждый элемент должен начинаться с новой строки и символа -. Ниже приведен наш пример записи:

%changelog
* Tue May 31 2016 Adam Miller <maxamillion@fedoraproject.org> - 0.1-1
- First cello package

Обратите внимание на приведенный выше формат, отметка даты будет начинаться с символа *, за которым следует календарный день недели, месяц, день месяца, год, затем контактная информация для упаковщика RPM. Оттуда у нас есть символ- перед выпуском версии, что является часто используемым, но не строго регламентированным. Затем, наконец, Версия-Релиз.

Вот и все! Мы написали целый файл спецификаций для cello!

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

Name:           cello
Version:        1.0
Release:        1%{?dist}
Summary:        Hello World example implemented in C

License:        GPLv3+
URL:            https://www.example.com/%{name}
Source0:        https://www.example.com/%{name}/releases/%{name}-%{version}.tar.gz

Patch0:         cello-output-first-patch.patch

BuildRequires:  gcc
BuildRequires:  make

%description
The long-tail description for our Hello World Example implemented in
C.

%prep
%setup -q

%patch0

%build
make %{?_smp_mflags}

%install
%make_install

%files
%license LICENSE
%{_bindir}/%{name}

%changelog
* Tue May 31 2016 Adam Miller <maxamillion@fedoraproject.org> - 1.0-1
- First cello package

Пакет rpmdevtools предоставляет набор шаблонов файлов спецификаций для нескольких популярных языков в каталоге/etc/rpmdevtools/.

Сборка RPMS

RPMs собираются с помощью команды rpmbuild. Различные сценарии и желаемые результаты требуют различных комбинаций аргументов для rpmbuild. В этом разделе описываются два основных сценария:

Команда rpmbuild ожидает определенную структуру каталогов и файлов. Это та же структура, что и в утилите rpmdev-setuptree. Предыдущие инструкции также подтвердили требуемую структуру.

Исходный RPMs

Зачем создавать исходный RPM (SRPM)?

Для сборки SRPM:

$ rpmbuild -bs _SPECFILE_

Замените SPECFILE именем SPEC файла. Параметр -bs "исходный код сборки".

Здесь мы собираем SRPMs для bello, pello и cello:

$ cd ~/rpmbuild/SPECS/

$ rpmbuild -bs bello.spec
Wrote: /home/admiller/rpmbuild/SRPMS/bello-0.1-1.el7.src.rpm

$ rpmbuild -bs pello.spec
Wrote: /home/admiller/rpmbuild/SRPMS/pello-0.1.1-1.el7.src.rpm

$ rpmbuild -bs cello.spec
Wrote: /home/admiller/rpmbuild/SRPMS/cello-1.0-1.el7.src.rpm

Обратите внимание, что SRPMS были помещены в каталог rpmbuild/SRPMS, который является частью структуры, ожидаемой rpmbuild.

Это все, что нужно для сборки SRPM.

Бинарный RPMS

Существует два метода сборки бинарных RPMs:

Восстановление из исходного RPM

Чтобы перестроить bello, pello и cello из исходных RPM (SRPMs), запустите:

$ rpmbuild --rebuild ~/rpmbuild/SRPMS/bello-0.1-1.el7.src.rpm
[output truncated]

$ rpmbuild --rebuild ~/rpmbuild/SRPMS/pello-0.1.1-1.el7.src.rpm
[output truncated]

$ rpmbuild --rebuild ~/rpmbuild/SRPMS/cello-1.0-1.el7.src.rpm
[output truncated]

Теперь Вы собрали RPM. Несколько заметок:

Создание бинарного файла из SPEC файла

Чтобы собрать bello, pello, и cello из их SPEC файлов, запустите:

$ rpmbuild -bb ~/rpmbuild/SPECS/bello.spec

$ rpmbuild -bb ~/rpmbuild/SPECS/pello.spec

$ rpmbuild -bb ~/rpmbuild/SPECS/cello.spec

Теперь Вы собрали RPM из SPEC файлов.

Большая часть информации, содержащейся в разделе Восстановление из исходного RPM применима здесь.

Проверка RPMs на корректность

После создания упаковки хорошо бы проверить её качество. Качество пакета, а не программного обеспечения, поставляемого в нём. Основным инструментом для этого является rpmlint. Это улучшает редактируемость RPM и обеспечивает проверку работоспособности и ошибок путем выполнения статического анализа RPM. Эта утилита может проверять бинарные RPM, исходные RPM (SRPMs) и spec файлы, поэтому она полезна на всех этапах упаковки, как показано в следующих примерах.

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

Проверка SPEC файла bello

Это результат выполнения rpmlint в SPEC файле bello:

$ rpmlint bello.spec
bello.spec: W: invalid-url Source0: https://www.example.com/bello/releases/bello-0.1.tar.gz HTTP Error 404: Not Found
0 packages and 1 specfiles checked; 0 errors, 1 warnings.

Наблюдения:

Это результат выполнения rpmlint на SRPM для bello:

$ rpmlint ~/rpmbuild/SRPMS/bello-0.1-1.el7.src.rpm
bello.src: W: invalid-url URL: https://www.example.com/bello HTTP Error 404: Not Found
bello.src: W: invalid-url Source0: https://www.example.com/bello/releases/bello-0.1.tar.gz HTTP Error 404: Not Found
1 packages and 0 specfiles checked; 0 errors, 2 warnings.

Наблюдения:

Проверка бинарного RPM bello

При проверке бинарных RPMs, rpmlint проверяет дополнительные параметры, в том числе:

Это результат выполненияrpmlint на бинарном RPM для bello:

$ rpmlint ~/rpmbuild/RPMS/noarch/bello-0.1-1.el7.noarch.rpm
bello.noarch: W: invalid-url URL: https://www.example.com/bello HTTP Error 404: Not Found
bello.noarch: W: no-documentation
bello.noarch: W: no-manual-page-for-binary bello
1 packages and 0 specfiles checked; 0 errors, 3 warnings.

Наблюдения:

Помимо вышеприведенных предупреждений, наш RPM проходит проверку rpmlint.

Проверка SPEC файла pello

Это результат выполнения rpmlint на SPEC файле pello:

$ rpmlint pello.spec
pello.spec:30: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name}
pello.spec:34: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.pyc
pello.spec:39: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name}/
pello.spec:43: E: hardcoded-library-path in /usr/lib/%{name}/
pello.spec:45: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.py*
pello.spec: W: invalid-url Source0: https://www.example.com/pello/releases/pello-0.1.1.tar.gz HTTP Error 404: Not Found
0 packages and 1 specfiles checked; 5 errors, 1 warnings.

Наблюдения:

Это результат выполнения rpmlint на SRPM pello:

$ rpmlint ~/rpmbuild/SRPMS/pello-0.1.1-1.el7.src.rpm
pello.src: W: invalid-url URL: https://www.example.com/pello HTTP Error 404: Not Found
pello.src:30: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name}
pello.src:34: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.pyc
pello.src:39: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name}/
pello.src:43: E: hardcoded-library-path in /usr/lib/%{name}/
pello.src:45: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.py*
pello.src: W: invalid-url Source0: https://www.example.com/pello/releases/pello-0.1.1.tar.gz HTTP Error 404: Not Found
1 packages and 0 specfiles checked; 5 errors, 2 warnings.

Наблюдения:

Проверка бинарного RPM pello

При проверке бинарного RPMs, rpmlint проверяет дополнительные параметры, в том числе:

Это результат выполнения rpmlint на бинарном RPM для pello:

$ rpmlint ~/rpmbuild/RPMS/noarch/pello-0.1.1-1.el7.noarch.rpm
pello.noarch: W: invalid-url URL: https://www.example.com/pello HTTP Error 404: Not Found
pello.noarch: W: only-non-binary-in-usr-lib
pello.noarch: W: no-documentation
pello.noarch: E: non-executable-script /usr/lib/pello/pello.py 0644L /usr/bin/env
pello.noarch: W: no-manual-page-for-binary pello
1 packages and 0 specfiles checked; 1 errors, 4 warnings.

Наблюдения:

Помимо вышеприведенных предупреждений и ошибок, наш RPM проходит проверку rpmlint.

Проверка SPEC файла cello

Это результат выполнения rpmlint на SPEC файле cello:

$ rpmlint ~/rpmbuild/SPECS/cello.spec
/home/admiller/rpmbuild/SPECS/cello.spec: W: invalid-url Source0: https://www.example.com/cello/releases/cello-1.0.tar.gz HTTP Error 404: Not Found
0 packages and 1 specfiles checked; 0 errors, 1 warnings.

Наблюдения:

Это результат выполнения rpmlint в файле SRPM для cello:

$ rpmlint ~/rpmbuild/SRPMS/cello-1.0-1.el7.src.rpm
cello.src: W: invalid-url URL: https://www.example.com/cello HTTP Error 404: Not Found
cello.src: W: invalid-url Source0: https://www.example.com/cello/releases/cello-1.0.tar.gz HTTP Error 404: Not Found
1 packages and 0 specfiles checked; 0 errors, 2 warnings.

Наблюдения:

Проверка бинарного RPM cello

При проверке бинарных RPMs, rpmlint проверяет дополнительные параметры, в том числе:

Это результат выполнения rpmlint на бинарном RPM для cello:

$ rpmlint ~/rpmbuild/RPMS/x86_64/cello-1.0-1.el7.x86_64.rpm
cello.x86_64: W: invalid-url URL: https://www.example.com/cello HTTP Error 404: Not Found
cello.x86_64: W: no-documentation
cello.x86_64: W: no-manual-page-for-binary cello
1 packages and 0 specfiles checked; 0 errors, 3 warnings.

Наблюдения:

Помимо вышеприведенных предупреждений и ошибок, наш RPM проходит проверку rpmlint.

Наши RPM теперь готовы и проверены с помощью rpmlint. На этом учебное пособие заканчивается. Для получения дополнительной информации о RPM упаковке перейдите к главе Дополнительные материалы.

Дополнительные материалы

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

Подпись пакетов

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

Существует три способа подписи пакета:

Добавление подписи к пакету

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

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

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

С двумя подписями пакеи попадает к продавцу. Продавец проверяет подписи и, если они проверяются, также добавляет свою подпись.

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

Вывод из команды --addsign:

$ rpm --addsign blather-7.9-1.i386.rpm
            Enter pass phrase:

Pass phrase is good.
blather-7.9-1.i386.rpm:

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

$ rpm --checksig blather-7.9-1.i386.rpm
blather-7.9-1.i386.rpm: size pgp pgp md5 OK

Два обозначения pgp в выходных данных команды rpm --checksig показывают, что пакет был подписан дважды.

RPM позволяет добавлять одну и ту же подпись несколько раз. Параметр --addsign не проверяет наличие нескольких идентичных подписей.

$ rpm --addsig blather-7.9-1.i386.rpm
              Enter pass phrase:

Pass phrase is good.
blather-7.9-1.i386.rpm:
$ rpm --addsig blather-7.9-1.i386.rpm
              Enter pass phrase:

Pass phrase is good.
blather-7.9-1.i386.rpm:
$ rpm --addsig blather-7.9-1.i386.rpm
              Enter pass phrase:

Pass phrase is good.
blather-7.9-1.i386.rpm:
$ rpm --checksig blather-7.9-1.i386.rpm
blather-7.9-1.i386.rpm: size pgp pgp pgp pgp md5 OK

На выходе команды rpm --checksig отображается четыре подписи.

Замена подписи пакета

Чтобы изменить открытый ключ без необходимости пересобирать каждый пакет, используйте опцию --resign.

$ rpm --resign blather-7.9-1.i386.rpm
            Enter pass phrase:

Pass phrase is good.
blather-7.9-1.i386.rpm:

Использование опции --resign с несколькими пакетами:

$ rpm --resign b*.rpm
            Enter pass phrase:

Pass phrase is good.
blather-7.9-1.i386.rpm:
bother-3.5-1.i386.rpm:

Подпись во время сборки

Чтобы подписать пакет во время сборки, используйте команду rpmbuild с параметром --sign. Для этого необходимо ввести кодовую фразу PGP.

Для примера:

$ rpmbuild -ba --sign blather-7.9.spec
            Enter pass phrase:

Pass phrase is good.
* Package: blather
…
Binary Packaging: blather-7.9-1
Finding dependencies...
…
Generating signature: 1002
Wrote: /usr/src/redhat/RPMS/i386/blather-7.9-1.i386.rpm
…
Source Packaging: blather-7.9-1
…
Generating signature: 1002
Wrote: /usr/src/redhat/SRPMS/blather-7.9-1.src.rpm

Сообщение "Generating signature" появляется как в бинарном, так и в исходном разделах упаковки. Число, следующее за сообщением, указывает на то, что добавленная подпись была создана с использованием PGP.

Чтобы проверить подпись пакета, используйте комманду --checksig. Для примера:

$ rpm --checksig blather-7.9-1.i386.rpm
blather-7.9-1.i386.rpm: size pgp md5 OK

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

При сборке нескольких пакетов используйте следующий синтаксис, чтобы избежать многократного ввода кодовой фразы PGP. Например, при сборке пакетов blather и bother, подпишите их, следуя примеру ниже:

$ rpmbuild -ba --sign b*.spec
              Enter pass phrase:

Pass phrase is good.
* Package: blather
…
Binary Packaging: blather-7.9-1
…
Generating signature: 1002
Wrote: /usr/src/redhat/RPMS/i386/blather-7.9-1.i386.rpm
…
Source Packaging: blather-7.9-1
…
Generating signature: 1002
Wrote: /usr/src/redhat/SRPMS/blather-7.9-1.src.rpm
…
* Package: bother
…
Binary Packaging: bother-3.5-1
…
Generating signature: 1002
Wrote: /usr/src/redhat/RPMS/i386/bother-3.5-1.i386.rpm
…
Source Packaging: bother-3.5-1
…
Generating signature: 1002
Wrote: /usr/src/redhat/SRPMS/bother-3.5-1.src.rpm

Mock

Mock - это инструмент для сборки пакетов. Он может создавать пакеты для разных архитектур и разных версий Fedora или RHEL. Mock создает chroots и собирает в них пакеты. Его единственная задача - надежно заполнить chroot и попытаться собрать пакет в этом chroot.

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

Mock способен создавать RPM из управления конфигурацией исходного кода, если присутствует пакет mock-scm, а затем встраивать SRPM в RPMs. Смотрите –scm-enable в документации. (Из upstream документации)

Одним из наиболее распространенных вариантов для RPM-упаковщиков, использующих Mock , является создание так называемой “нетронутой среды сборки”. При использовании mock в качестве “нетронутой среды сборки”, ничто в текущем состоянии вашей системы не влияет на сам пакет RPM. Mock использует различные конфигурации, чтобы указать, какова “цель” сборки, они находятся в Вашей системе в каталоге/etc/mock/ (после установки пакета mock). Вы можете выполнить сборку для разных дистрибутивов или выпусков, просто указав это в командной строке. Следует иметь в виду, что файлы конфигурации, поставляемые с макетом, предназначены для упаковщиков Fedora RPM, и поэтому выпускаемые версии RHEL и CentOS помечены как “epel” , потому что это «целевой» репозиторий, для которого эти RPM пакеты будут созданы. Вы просто указываете конфигурацию, которую хотите использовать (без расширения файла .cfg). Например, вы можете создать наш пример cello как для RHEL 7, так и для Fedora 23, используя следующие команды, даже не используя разные машины.

$ mock -r epel-7-x86_64 ~/rpmbuild/SRPMS/cello-1.0-1.el7.src.rpm

$ mock -r fedora-23-x86_64 ~/rpmbuild/SRPMS/cello-1.0-1.el7.src.rpm

Один из примеров того, почему Вы можете захотеть использовать mock - это если вы упаковывали RPMs на своем ноутбуке, и у Вас был установлен пакет (в этом примере мы назовем его foo), который был указан в секции BuildRequires того пакета, который Вы собирали, но забыли фактически сделать запись BuildRequires: foo. Сборка завершится успешно, когда вы запуститеrpmbuild, потому чтоfoo был необходим для сборки, и он был найден в системе во время сборки. Однако, если Вы перенесёте SRPM в другую систему, в которой отсутствовал foo, он выйдет из строя, что вызовет неожиданный побочный эффект. Mock решает эту проблему, сначала анализируя содержимое SRPM и устанавливая BuildRequires в его chroot, что означает, что если бы Вам не хватало записи BuildRequires , сборка завершилась бы с ошибкой, потому что mock не знал бы, как её установить, и поэтому она не присутствовала бы в buildroot.

Другой пример - противоположный сценарий, допустим, Вам нужен gcc для сборки пакета, но он не установлен в вашей системе (что маловероятно для RPM-упаковщика, но просто ради примера давайте притворимся, что это правда). С Mock, Вам не нужно устранавливать gcc в Вашей системе, потому что он будет установлен в chroot как часть процесса mock.

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

$ rpmbuild --rebuild ~/rpmbuild/SRPMS/cello-1.0-1.el7.src.rpm
Installing /home/admiller/rpmbuild/SRPMS/cello-1.0-1.el7.src.rpm
error: Failed build dependencies: gcc is needed by cello-1.0-1.el7.x86_64

$ mock -r epel-7-x86_64 ~/rpmbuild/SRPMS/cello-1.0-1.el7.src.rpm
INFO: mock.py version 1.2.17 starting (python version = 2.7.5)...
Start: init plugins
INFO: selinux enabled
Finish: init plugins
Start: run
INFO: Start(/home/admiller/rpmbuild/SRPMS/cello-1.0-1.el7.src.rpm)  Config(epel-7-x86_64)
Start: clean chroot
Finish: clean chroot
Start: chroot init
INFO: calling preinit hooks
INFO: enabled root cache
Start: unpacking root cache
Finish: unpacking root cache
INFO: enabled yum cache
Start: cleaning yum metadata
Finish: cleaning yum metadata
Mock Version: 1.2.17
INFO: Mock Version: 1.2.17
Start: yum update
base                                                                    | 3.6 kB  00:00:00
epel                                                                    | 4.3 kB  00:00:00
extras                                                                  | 3.4 kB  00:00:00
updates                                                                 | 3.4 kB  00:00:00
No packages marked for update
Finish: yum update
Finish: chroot init
Start: build phase for cello-1.0-1.el7.src.rpm
Start: build setup for cello-1.0-1.el7.src.rpm
warning: Could not canonicalize hostname: rhel7
Building target platforms: x86_64
Building for target x86_64
Wrote: /builddir/build/SRPMS/cello-1.0-1.el7.centos.src.rpm
Getting requirements for cello-1.0-1.el7.centos.src
 --> Already installed : gcc-4.8.5-4.el7.x86_64
 --> Already installed : 1:make-3.82-21.el7.x86_64
No uninstalled build requires
Finish: build setup for cello-1.0-1.el7.src.rpm
Start: rpmbuild cello-1.0-1.el7.src.rpm
Building target platforms: x86_64
Building for target x86_64
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.v9rPOF
+ umask 022
+ cd /builddir/build/BUILD
+ cd /builddir/build/BUILD
+ rm -rf cello-1.0
+ /usr/bin/gzip -dc /builddir/build/SOURCES/cello-1.0.tar.gz
+ /usr/bin/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd cello-1.0
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
Patch #0 (cello-output-first-patch.patch):
+ echo 'Patch #0 (cello-output-first-patch.patch):'
+ /usr/bin/cat /builddir/build/SOURCES/cello-output-first-patch.patch
patching file cello.c
+ /usr/bin/patch -p0 --fuzz=0
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.UxRVtI
+ umask 022
+ cd /builddir/build/BUILD
+ cd cello-1.0
+ make -j2
gcc -g -o cello cello.c
+ exit 0
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.K3i2dL
+ umask 022
+ cd /builddir/build/BUILD
+ '[' /builddir/build/BUILDROOT/cello-1.0-1.el7.centos.x86_64 '!=' / ']'
+ rm -rf /builddir/build/BUILDROOT/cello-1.0-1.el7.centos.x86_64
++ dirname /builddir/build/BUILDROOT/cello-1.0-1.el7.centos.x86_64
+ mkdir -p /builddir/build/BUILDROOT
+ mkdir /builddir/build/BUILDROOT/cello-1.0-1.el7.centos.x86_64
+ cd cello-1.0
+ /usr/bin/make install DESTDIR=/builddir/build/BUILDROOT/cello-1.0-1.el7.centos.x86_64
mkdir -p /builddir/build/BUILDROOT/cello-1.0-1.el7.centos.x86_64/usr/bin
install -m 0755 cello /builddir/build/BUILDROOT/cello-1.0-1.el7.centos.x86_64/usr/bin/cello
+ /usr/lib/rpm/find-debuginfo.sh --strict-build-id -m --run-dwz --dwz-low-mem-die-limit 10000000 --dwz-max-die-limit 110000000 /builddir/build/BUILD/cello-1.0
extracting debug info from /builddir/build/BUILDROOT/cello-1.0-1.el7.centos.x86_64/usr/bin/cello
dwz: Too few files for multifile optimization
/usr/lib/rpm/sepdebugcrcfix: Updated 0 CRC32s, 1 CRC32s did match.
+ /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/redhat/brp-compress
+ /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
+ /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
+ /usr/lib/rpm/redhat/brp-python-hardlink
+ /usr/lib/rpm/redhat/brp-java-repack-jars
Processing files: cello-1.0-1.el7.centos.x86_64
Executing(%license): /bin/sh -e /var/tmp/rpm-tmp.vxtAuO
+ umask 022
+ cd /builddir/build/BUILD
+ cd cello-1.0
+ LICENSEDIR=/builddir/build/BUILDROOT/cello-1.0-1.el7.centos.x86_64/usr/share/licenses/cello-1.0
+ export LICENSEDIR
+ /usr/bin/mkdir -p /builddir/build/BUILDROOT/cello-1.0-1.el7.centos.x86_64/usr/share/licenses/cello-1.0
+ cp -pr LICENSE /builddir/build/BUILDROOT/cello-1.0-1.el7.centos.x86_64/usr/share/licenses/cello-1.0
+ exit 0
Provides: cello = 1.0-1.el7.centos cello(x86-64) = 1.0-1.el7.centos
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires: libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) rtld(GNU_HASH)
Processing files: cello-debuginfo-1.0-1.el7.centos.x86_64
Provides: cello-debuginfo = 1.0-1.el7.centos cello-debuginfo(x86-64) = 1.0-1.el7.centos
Requires(rpmlib): rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files /builddir/build/BUILDROOT/cello-1.0-1.el7.centos.x86_64
Wrote: /builddir/build/RPMS/cello-1.0-1.el7.centos.x86_64.rpm
warning: Could not canonicalize hostname: rhel7
Wrote: /builddir/build/RPMS/cello-debuginfo-1.0-1.el7.centos.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.JuPOtY
+ umask 022
+ cd /builddir/build/BUILD
+ cd cello-1.0
+ /usr/bin/rm -rf /builddir/build/BUILDROOT/cello-1.0-1.el7.centos.x86_64
+ exit 0
Finish: rpmbuild cello-1.0-1.el7.src.rpm
Finish: build phase for cello-1.0-1.el7.src.rpm
INFO: Done(/home/admiller/rpmbuild/SRPMS/cello-1.0-1.el7.src.rpm) Config(epel-7-x86_64) 0 minutes 16 seconds
INFO: Results and/or logs in: /var/lib/mock/epel-7-x86_64/result
Finish: run

Как Вы можете видеть, mock - довольно подробный инструмент. Вы также заметите много выходных данных yum или dnf (в зависимости от фиктивной цели RHEL7, CentOS7 или Fedora), которых нет в этом выводе, который был опущен для краткости и часто опускается после того, как Вы выполнили --init для mock target. Например mock -r epel-7-x86_64 --init, который предварительно загрузит все необходимые пакеты, закэширует их и запустит предварительный этап сборки chroot.

Для получения дополнительной информации, пожалуйста, обратитесь к Mock upstream документации.

Система контроля версий

При работе с RPMs желательно использовать Системы контроля версий (VCS), такую как git, для управления компонентами программного обеспечения, которое мы упаковываем. Следует отметить, что хранение бинарных файлов в системе контроля версий нецелесообразно, поскольку это резко увеличивает размер исходного репозитория, поскольку эти инструменты разработаны для обработки различий в файлах (часто оптимизированных для текстовых файлов), чему не поддаются бинарные файлы, поэтому обычно сохраняется весь бинарные файл целиком. Существуют некоторые утилиты, популярные среди upstream проектов с открытым исходным кодом, которые решают эту проблему, либо сохраняя SPEC файл, где исходный код находится в VCS (т. е. - он не находится в сжатом архиве для распространения ), либо помещая в VCS только SPEC-файл и патчи и загружается сжатый архив updtream исходного кода в так называемый «кэш просмотра».

В этом разделе мы рассмотрим два различных варианта использования системы контроля версий git для управления содержимым, которое в конечном итоге будет преобразовано в пакет RPM. Первый называется tito, второй - dist-git.

tito

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

Давайте немного познакомимся с tito, взглянув на исходный проект, который уже использует его. На самом деле мы будем использовать репозиторий git проекта, который является предметом нашего следующего раздела, dist-git. Поскольку этот проект публично размещен на GitHub, давайте клонируем репозиторий git.

$ git clone https://github.com/release-engineering/dist-git.git
Cloning into 'dist-git'...
remote: Counting objects: 425, done.
remote: Total 425 (delta 0), reused 0 (delta 0), pack-reused 425
Receiving objects: 100% (425/425), 268.76 KiB | 0 bytes/s, done.
Resolving deltas: 100% (184/184), done.
Checking connectivity... done.

$ cd dist-git/

$ ls *.spec
dist-git.spec

$ tree rel-eng/
rel-eng/
├── packages
│   └── dist-git
└── tito.props

1 directory, 2 files

Как мы видим, SPEC файл находится в корне репозитория git, и в репозитории есть каталог rel-eng, который используется tito для общего учета, настройки и различных дополнительных тем, таких как пользовательские модули tito. В макете каталога мы видим, что есть подкаталог с названием packages, в котором будет храниться файл для каждого пакета, которым tito управляет в репозитории, поскольку у Вас может быть много RPM в одном репозитории git, и tito справится с этим просто отлично. Однако, в этом сценарии мы видим только один список пакетов, и следует отметить, что он соответствует имени нашего SPEC файла. Все это настраивается командой tito init, когда разработчики dist-git впервые инициализировали свой репозиторий git для управления tito.

Если бы мы следовали обычному рабочему процессу DevOps Practitioner, мы, вероятно, хотели бы использовать его как часть процесса Непрерывной интеграции (CI) или Непрерывной доставки (CD). Что мы можем сделать в этом сценарии, так это выполнить “test build” для tito, мы даже можем использовать mock. Затем мы могли бы использовать выходные данные в качестве точки установки для какого-либо другого компонента в конвейере. Ниже приведен простой пример команд, которые могут это сделать, и их можно адаптировать к другим средам.

$ tito build --test --srpm
Building package [dist-git-0.13-1]
Wrote: /tmp/tito/dist-git-git-0.efa5ab8.tar.gz

Wrote: /tmp/tito/dist-git-0.13-1.git.0.efa5ab8.fc23.src.rpm

$ tito build --builder=mock --arg mock=epel-7-x86_64 --test --rpm
Building package [dist-git-0.13-1]
Creating rpms for dist-git-git-0.efa5ab8 in mock: epel-7-x86_64
Wrote: /tmp/tito/dist-git-git-0.efa5ab8.tar.gz

Wrote: /tmp/tito/dist-git-0.13-1.git.0.efa5ab8.fc23.src.rpm

Using srpm: /tmp/tito/dist-git-0.13-1.git.0.efa5ab8.fc23.src.rpm
Initializing mock...
Installing deps in mock...
Building RPMs in mock...
Wrote:
  /tmp/tito/dist-git-selinux-0.13-1.git.0.efa5ab8.el7.centos.noarch.rpm
  /tmp/tito/dist-git-0.13-1.git.0.efa5ab8.el7.centos.noarch.rpm

$ sudo yum localinstall /tmp/tito/dist-git-*.noarch.rpm
Loaded plugins: product-id, search-disabled-repos, subscription-manager
Examining /tmp/tito/dist-git-0.13-1.git.0.efa5ab8.el7.centos.noarch.rpm: dist-git-0.13-1.git.0.efa5ab8.el7.centos.noarch
Marking /tmp/tito/dist-git-0.13-1.git.0.efa5ab8.el7.centos.noarch.rpm to be installed
Examining /tmp/tito/dist-git-selinux-0.13-1.git.0.efa5ab8.el7.centos.noarch.rpm: dist-git-selinux-0.13-1.git.0.efa5ab8.el7.centos.noarch
Marking /tmp/tito/dist-git-selinux-0.13-1.git.0.efa5ab8.el7.centos.noarch.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package dist-git.noarch 0:0.13-1.git.0.efa5ab8.el7.centos will be installed

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

На этом наш простой пример использования tito заканчивается, но в нём есть много удивительных функций для системных администраторов, разработчиков RPM-пакетов и практиков DevOps. Я бы настоятельно рекомендовал ознакомиться с upstream документацией, найденной на сайте tito GitHub, для получения дополнительной информации о том, как быстро начать использовать его для вашего проекта, а также о различных дополнительных функциях, которые он предлагает.

dist-git

Утилита dist-git использует несколько иной подход, чем у tito, так что вместо того, чтобы хранить исходный код в git, она вместо этого будет хранить файлы спецификаций и патчи в репозитории git и загружать сжатый архив исходного кода в так называемый “look-aside cache”. “Look-aside-cache” - это термин, который был придуман при использовании систем сборки RPM, хранящих большие файлы, подобные этим, “на стороне”. Подобная система, как правило, привязана к правильной системе сборки RPM, такой как Koji. Затем система сборки настраивается на извлечение элементов, которые перечислены в качестве записей SourceX в файлах спецификаций из этого внешнего кэша, в то время как SPEC файл и исправления остаются в системе контроля версий. Существует также вспомогательный инструмент командной строки, который поможет в этом.

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

Подробнее о макросах

Существует множество встроенных макросов RPM, и мы рассмотрим некоторые из них в следующем разделе, однако исчерпывающий список можно найти на странице RPM Official Documentation.

Существуют также макросы, предоставляемые Вашим дистрибутивом Linux, в этом разделе мы рассмотрим некоторые из них, предоставляемые Fedora, CentOS и RHEL, а также предоставим информацию о том, как проверить Вашу систему, чтобы узнать о других, которые мы не рассматриваем, или для их обнаружения в других дистрибутивах Linux на основе RPM

Определение Ваших Собственных Макросов

Вы можете определить свои собственные макросы. Ниже приводится выдержка из RPM Official Documentation, в которой содержится исчерпывающая информация о возможностях макросов.

Чтобы определить макрос, используйте:

%global <name>[(opts)] <body>

Все пробелы, окружающие \ , удаляются. Имя может состоять из буквенно-цифровых символов и символа _, и должно иметь длину не менее 3 символов. Макрос без поля (opts) является “простым” в том смысле, что выполняется только рекурсивное расширение макроса. Параметризованный макрос содержит поле (opts) field. The opts - (строка в круглых скобках) передается точно так же, как и в getopt(3) для обработки argc/argv в начале вызова макроса.

Пример:

%global githash 0ec4e58
%global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())")

%setup

Макрос %setup можно использовать для сборки пакета с помощью tarball. Стандартное поведение макроса %setup можно увидеть в выходных данных rpmbuild. В начале каждой фазы макрос выводит Executing(%something). Например:

Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.DhddsG

Выходные данные оболочки устанавливаются с включенным set -x. Чтобы просмотреть содержимое /var/tmp/rpm-tmp.DhddsG, используйте опцию --debug, поскольку rpmbuild удаляет временные файлы после успешной сборки. Здесь отображается настройка переменных среды, например:

cd '/builddir/build/BUILD'
rm -rf 'cello-1.0'
/usr/bin/gzip -dc '/builddir/build/SOURCES/cello-1.0.tar.gz' | /usr/bin/tar -xof -
STATUS=$?
if [ $STATUS -ne 0 ]; then
  exit $STATUS
fi
cd 'cello-1.0'
/usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .

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

%setup -q

Параметр -q ограничивает детализацию макроса %setup. Вместо tar -xof выполняется только tar -xvvof. Этот параметр должен быть использован в качестве первого.

%setup -n

В некоторых случаях каталог из расширенного архива имеет другое имя, чем ожидалось %{name}-%{version}. Это может привести к ошибке макроса %setup. Имя каталога должно быть указано параметром -n directory_name.

Например, если имя пакета cello, но исходный код заархивирован в hello-1.0.tgz и содержит каталог hello/, содержимое SPEC файла должно быть следующим:

Name: cello
Source0: https://example.com/%{name}/release/hello-%{version}.tar.gz
…
%prep
%setup -n hello

%setup -c

Параметр -c можно использовать, если архив исходного кода не содержит никаких подкаталогов и после распаковки файлы из архива заполняют текущий каталог. Опция -c создает каталог и переходит к расширению архива. Наглядный пример:

/usr/bin/mkdir -p cello-1.0
cd 'cello-1.0'

Каталог не изменяется после расширения архива.

%setup -D и -T

Параметр -D отключает удаление каталога исходного кода. Этот параметр полезен, если макрос %setup используется несколько раз. По сути, параметр -D означает, что сделующие строки не используются:

rm -rf 'cello-1.0'

Параметр-T отключает расширение хранилища исходного кода, удаляя следующую строку из скрипта:

/usr/bin/gzip -dc '/builddir/build/SOURCES/cello-1.0.tar.gz' | /usr/bin/tar -xvvof -

%setup -a и -b

Параметры -a и -b расширяют определённые источники.

Например, допустим, что архив cello-1.0.tar.gz содержит пустой каталог examples, и примеры поставляются в отдельных examples.tar.gz tarball архивах, и они разархивируются в каталог с тем же именем. В этом случае используйте -a 1, так как мы хотим разархивировать Source1 после входа в рабочий каталог:

Source0: https://example.com/%{name}/release/%{name}-%{version}.tar.gz
Source1: examples.tar.gz
…
%prep
%setup -a 1

Но если бы примеры были в отдельном cello-1.0-examples.tar.gz tarball архиве, который расширяется до cello-1.0/examples, используйте параметры -b 1, поскольку Source1 должен быть разархивирован перед входом в рабочий каталог:

Source0: https://example.com/%{name}/release/%{name}-%{version}.tar.gz
Source1: %{name}-%{version}-examples.tar.gz
…
%prep
%setup -b 1

Вы также можете использовать комбинацию всех этих опций.

%files

Общие “расширенные” макросы RPM, необходимые в разделе %files:

Встроенные макросы

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

Вы также можете найти информацию о макросах RPM, которые поставляются непосредственно с версией RPM Вашей системы, просмотрев выходные данные rpm -ql rpm , обратив внимание на файлы с названием macros в структуре каталогов.

RPM Макросы, предоставляемые дистрибутивом

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

Они часто предоставляются в виде самих пакетов RPM и могут быть установлены с помощью пакетного менеджера, такого как yum или dnf. Сами файлы макросов после установки можно найти в /usr/lib/rpm/macros.d/, и они будут включены в вывод rpm --showrc по умолчанию после установки.

Одним из основных примеров этого является раздел Fedora Packaging Guidelines, относящийся конкретно к Application Specific Guidelines, который на момент написания этой статьи содержит более 60 различных наборов руководств вместе с соответствующими наборами макросов RPM для упаковки.

Одним из примеров такого рода RPM может быть Python версии 2.x, и если у нас установлен пакет python2-rpm-macros (доступный в EPEL для RHEL 7 и CentOS 7), у нас есть ряд доступных, специфичных для python2 макросов.

$ rpm -ql python2-rpm-macros
/usr/lib/rpm/macros.d/macros.python2

$ rpm --showrc | grep python2
-14: __python2  /usr/bin/python2
CFLAGS="%{optflags}" %{__python2} %{py_setup} %{?py_setup_args} build --executable="%{__python2} %{py2_shbang_opts}" %{?1}
CFLAGS="%{optflags}" %{__python2} %{py_setup} %{?py_setup_args} install -O1 --skip-build --root %{buildroot} %{?1}
-14: python2_sitearch   %(%{__python2} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib(1))")
-14: python2_sitelib    %(%{__python2} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())")
-14: python2_version    %(%{__python2} -c "import sys; sys.stdout.write('{0.major}.{0.minor}'.format(sys.version_info))")
-14: python2_version_nodots     %(%{__python2} -c "import sys; sys.stdout.write('{0.major}{0.minor}'.format(sys.version_info))")

В приведенном выше выводе отображаются необработанные определения макросов RPM, но нас, вероятно, больше интересует, что мы можем сделать с помощью rpm --eval , чтобы определить, что они делают, а также как они могут быть полезны для нас при упаковке RPMs.

$ rpm --eval %{__python2}
/usr/bin/python2

$ rpm --eval %{python2_sitearch}
/usr/lib64/python2.7/site-packages

$ rpm --eval %{python2_sitelib}
/usr/lib/python2.7/site-packages

$ rpm --eval %{python2_version}
2.7

$ rpm --eval %{python2_version_nodots}
27

Пользовательские макросы

Вы можете переопределить макросы в файле ~/.rpmmacros. Любые внесенные вами изменения повлияют на каждую сборку на Вашем компьютере.

Хотя Вы можете определить любые новые макросы в файле ~/.rpmmacros это не рекомендуется, поскольку эти макросы не будут присутствовать на других компьютерах, где пользователи могут захотеть попытаться пересобрать Ваш пакет.

Epoch, Скриптлеты и Триггеры

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

Epoch

Первым в списке стоит Epoch, epoch - это способ определения взвешенных зависимостей на основе номеров версий. Его значение по умолчанию равно 0, если директива Epoch не указана в SPEC файле. Это не рассматривалось в разделе "SPEC файл" этого руководства, потому что почти всегда вводить значени Epoch - плохая идея, поскольку это искажает то, что вы обычно ожидаете от RPM при сравнении версий пакетов.

Например, если был установлен пакет foobar с Epoch: 1 и Version: 1.0, а кто-то другой упаковал foobar сVersion: 2.0 , но просто опустил директиву Epoch либо потому, что они не знали о её необходимости, либо просто забыли, эта новая версия никогда не будет считаться обновлением, потому что версия Epoch превалирует над традиционным маркером Name-Version-Release, который означает управление версиями для RPM-пакетов.

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

Скриптлеты и Триггеры

В пакетах RPM существует ряд директив, которые можно использовать для внесения необходимых или желаемых изменений в систему во время установки RPM. Они называются скриптлеты.

Один из основных примеров того, когда и почему Вы хотели бы это сделать, это когда установлена системная служба RPM и она предоставляет systemd файл. Во время установки нам нужно будет уведомить systemd о появлении нового модуля, чтобы системный администратор мог выполнить команду, аналогичную systemctl start foo.service после установки вымышленного foo (который в этом примере предоставляет демон). Аналогично, нам нужно было бы отменить это действие при деинсталляции, чтобы администратор не получал ошибок из-за того, что бинарный файл демона больше не установлен, но файл модуля все еще существует в запущенной конфигурации systemd.

Существует небольшая горстка распространенных скриптлетов, они похожи на “заголовки разделов”, такие как %build or %install, в том смысле, что они определяются многострочными сегментами кода, часто написанными, как стандартный сценарий оболочки POSIX , но могут быть на нескольких разных языках программирования. Исчерпывающий список этих доступных языков можно найти в Официальной документации RPM.

Следующие скриптлеты:

Также часто для этой функции существуют макросы RPM. В нашем предыдущем примере мы обсуждали необходимость получения systemd уведомления о новом unit file, , это легко обрабатывается макросами скриптлетов systemd, как Мы можем видеть из приведенного ниже примера вывода. Более подробную информацию об этом можно найти в Fedora systemd Packaging Guidelines.

$ rpm --showrc | grep systemd
-14: __transaction_systemd_inhibit      %{__plugindir}/systemd_inhibit.so
-14: _journalcatalogdir /usr/lib/systemd/catalog
-14: _presetdir /usr/lib/systemd/system-preset
-14: _unitdir   /usr/lib/systemd/system
-14: _userunitdir       /usr/lib/systemd/user
/usr/lib/systemd/systemd-binfmt %{?*} >/dev/null 2>&1 || :
/usr/lib/systemd/systemd-sysctl %{?*} >/dev/null 2>&1 || :
-14: systemd_post
-14: systemd_postun
-14: systemd_postun_with_restart
-14: systemd_preun
-14: systemd_requires
Requires(post): systemd
Requires(preun): systemd
Requires(postun): systemd
-14: systemd_user_post  %systemd_post --user --global %{?*}
-14: systemd_user_postun        %{nil}
-14: systemd_user_postun_with_restart   %{nil}
-14: systemd_user_preun
systemd-sysusers %{?*} >/dev/null 2>&1 || :
echo %{?*} | systemd-sysusers - >/dev/null 2>&1 || :
systemd-tmpfiles --create %{?*} >/dev/null 2>&1 || :

$ rpm --eval %{systemd_post}

if [ $1 -eq 1 ] ; then
        # Initial installation
        systemctl preset  >/dev/null 2>&1 || :
fi

$ rpm --eval %{systemd_postun}

systemctl daemon-reload >/dev/null 2>&1 || :

$ rpm --eval %{systemd_preun}

if [ $1 -eq 0 ] ; then
        # Package removal, not upgrade
        systemctl --no-reload disable  > /dev/null 2>&1 || :
        systemctl stop  > /dev/null 2>&1 || :
fi

Еще один элемент, который обеспечивает еще более детальный контроль над транзакцией RPM в целом, - это то, что известно как триггеры. По сути, это то же самое, что и скриптлет, но выполняется в очень определенном порядке операций во время транзакции установки или обновления RPM, что позволяет более точно контролировать весь процесс.

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

all-%pretrans
...
any-%triggerprein (%triggerprein from other packages set off by new install)
new-%triggerprein
new-%pre      for new version of package being installed
...           (all new files are installed)
new-%post     for new version of package being installed

any-%triggerin (%triggerin from other packages set off by new install)
new-%triggerin
old-%triggerun
any-%triggerun (%triggerun from other packages set off by old uninstall)

old-%preun    for old version of package being removed
...           (all old files are removed)
old-%postun   for old version of package being removed

old-%triggerpostun
any-%triggerpostun (%triggerpostun from other packages set off by old un
            install)
...
all-%posttrans

Вышеуказанные элементы взяты из прилагаемой документации RPM, найденной в /usr/share/doc/rpm/triggers на системах Fedora и /usr/share/doc/rpm-4.*/triggers в системах RHEL 7 и CentOS 7.

Использование скриптов без оболочки в SPEC файле

Параметр скриптлета -p, в SPEC файле позволяет вызывать определенный интерпретатор вместо стандартного -p /bin/sh. Наглядным примером является скрипт, который выводит сообщение после установки pello.py.

Условные обозначения RPM

Условные обозначения RPM позволяют условно включать различные разделы SPEC файла.

Чаще всего условные обозначения имеют дело с:

Синтаксис условий RPM

Если expression истинно, то выполните какое-нибудь действие:

%if expression
...
%endif

Если expression истинно, то выполните какое-нибудь действие, в другом случае выполните другое действие:

%if expression
...
%else
...
%endif

Примеры условий RPM

Обозначение %if

%if 0%{?rhel} == 6
sed -i '/AS_FUNCTION_DESCRIBE/ s/^/#/' configure.in
sed -i '/AS_FUNCTION_DESCRIBE/ s/^/#/' acinclude.m4
%endif

Это условие обрабатывает совместимость между RHEL6 и другими операционными системами с точки зрения поддержки макроса AS_FUNCTION_DESCRIBE. Когда пакет создается для RHEL, определяется макрос %rhel , и он расширяется до версии RHEL. Если его значение равно 6, что означает, что пакет создан для RHEL 6, , то ссылки на AS_FUNCTION_DESCRIBE, который не поддерживается RHEL6, удаляются из сценариев автоконфигурации.

%if 0%{?el6}
%global ruby_sitearch %(ruby -rrbconfig -e 'puts Config::CONFIG["sitearchdir"]')
%endif

Это условие регулирует совместимость между Fedora версии 17 и новее и RHEL 6 с точки зрения поддержки макроса %ruby_sitearch macro. Fedora версии 17 и никогда не определяет %ruby_sitearch по умолчанию, но RHEL6 не поддерживает этот макрос. Условие проверяет, является ли операционная система RHEL 6. Если это так, %ruby_sitearch определяется явно. Обратите внимание, что 0%{?el6} имеет то же значение, что и 0%{?rhel} == 6 из предыдущего примера, и он проверяет, построен ли пакет на RHEL 6.

%if 0%{?fedora} >= 19
%global with_rubypick 1
%endif

Это условие обрабатывает поддержку инструмента выбора ruby. Если операционная система Fedora версии 19 или новее, поддерживается rubypick.

%define ruby_archive %{name}-%{ruby_version}
%if 0%{?milestone:1}%{?revision:1} != 0
%define ruby_archive %{ruby_archive}-%{?milestone}%{?!milestone:%{?revision:r%{revision}}}
%endif

Это условие обрабатывает определение макросов. Если заданы макросы %milestone или %revision, переопределяется макрос %ruby_archive, который определяет имя вышестоящего файла архива.

Специальные варианты обозначения %if

Условные обозначения %ifarch, %ifnarch и %ifos являются специализированными вариантами условных обозначений %if. Эти варианты обычно используются, поэтому у них есть свои собственные макросы.

Обозначение`%ifarch`

Условие %ifarch спользуется для начала блока SPEC файла, который зависит от архитектуры. За ним следует один или несколько спецификаторов архитектуры, каждый из которых разделен запятыми или пробелами.

%ifarch i386 sparc
...
%endif

Все содержимое SPEC файла между %ifarch и %endif обрабатывается только на 32-разрядных архитектурах AMD и Intel или системах на базе Sun SPARC.

Условное обозначение %ifnarch

Условие %ifnarch имеет обратную логику, чем условие %ifarch.

%ifnarch alpha
...
%endif

Все содержимое SPEC файла между %ifnarch и %endif обрабатывается только в том случае, если оно не выполняется в системе на основе Digital Alpha/AXP.

Условие %ifos

Условие %ifos используется для управления обработкой на основе операционной системы сборки. За ним может следовать одно или несколько имен операционной системы.

%ifos linux
...
%endif

Все содержимое SPEC файла между %ifos и %endif обрабатывается только в том случае, если сборка была выполнена в системе Linux.

Appendix A: Новые возможности RPM в RHEL 7

Этот список документирует наиболее заметные изменения в упаковке RPM между Red Hat Enterprise Linux 6 и 7.

Appendix B: Ссылки на источники

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

Software Collections - SoftwareCollections.org это проект с открытым исходным кодом для создания и распространения поддерживаемых сообществом коллекций программного обеспечения (SCL) для Red Hat Enterprise Linux, Fedora, CentOS, и Scientific Linux.

Creating RPM package - Пошаговое руководство по изучению основ упаковки RPM.

Packaging software with RPM, Part 1, Part 2, Part 3 - Руководство по упаковке IBM RPM.

RPM Documentation - Официальная документация RPM.

Fedora Packaging Guidelines - Официальные рекомендации по упаковке для Fedora, полезные для всех дистрибутивов на основе RPM.

rpmfluff - библиотека python для создания пакетов RPM и их саботажа, чтобы они были взломаны контролируемыми способами.

Appendix C: Выражение благодарности

Некоторые фрагменты этого текста впервые появились в RPM Packaging Guide. Copyright © 2020 Adam Miller and others. Лицензировано в соответствии с Creative Commons Attribution-ShareAlike 3.0 Unported License.

Список используемых источников

• Руководство по сборке RPM пакетов
• Conditionals