Обзор структуры и особенностей RPM-пакетов в отечественных ОС: ОС ALT, РЭД ОС и Rosa Linux

ОС ALT

РЭД ОС

ROSA LINUX

RED HAT

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

• 1.    RPM;

• 2.    APT

• 1.    RPM;

• 2.    DNF

1. RPM

Структура каталогов

~/rpm/BUILD — каталог       для

собранных исходников;

~/rpm/tmp — для временных файлов, которые создаются программой rpm во время сборки пакетов; 1

~/rpm/RPMS — каталоги     для

различных архитектур,   для

которых планируется выполнять сборку (обычно это i586 или x86_64, но может быть также sparc, alpha или ppc).

BUILD — содержит  все

файлы, появляющиеся при    сборке

пакета.

RPMS — здесь появятся готовые бинарные пакеты (расширение .rpm).

SOURCES — здесь должны находиться исходники, из которых     и

будут собираться RPM-пакеты.

SPECS — папка     для

хранения spec-файла, который описывает

%_topdir — каталог верхнего уровня, содержащий в себе

стандартную иерархию каталогов RPM, в      которой

производится сборка пакета. По умолчанию значение этого макроса равно $HOME/RPM;

%_sourcedir — макрос, указывающий на каталог с исходными кодами программы, собираемой  в

пакет. Значение по умолчанию — %_topdir/SOUR CES;

~/rpm/BUILD для собранных исходников.

~/rpm/RPMS каталоги для разных архитектур, куда кладутся бинарные пакеты после сборки

~/rpm/RPMS/i 586 —

каталог для хранения rpm-пакетов для процессоров i586;

~/rpm/RPMS/ x86_64 каталог для хранения rpm-пакетов для

процесс сборки.

SRPMS —

здесь находятся пакеты      с

исходниками (расширение .src.rpm).

%_specdir — каталог, содержащий spec-файл.

Значение    по

умолчанию — %_topdir/SPEC S; 1

%_srcrpmdir — каталог, в котором будет содержаться собранный пакет         с

исходным кодом (src.rpm). Значение    по

умолчанию — %_topdir/SRPM S; 1

%_rpmdir/%_a rch — каталог, содержащий подкаталоги  с

именами различных архитектур (%_arch),   для

которых производится сборка пакета. Собранный бинарный пакет будет помещён в один из этих подкаталогов. Значение макроса %_rpmdir   по

умолчанию — %_topdir/RPMS.

процессоров x86_64;

~/rpm/RPMS/ noarch — каталог для хранения rpm-пакетов, не зависящих от архитектуры процессора.

~/rpm/SOURC ES. файлы исходного кода.

~/rpm/SPECS. В этом каталоге хранятся спек-файлы.

~/rpm/SRPMS . Каталог src.rpm-пакетов.

~/rpm/tmp. Здесь находятся временные файлы.

Сборка пакета

• 1.    сборка командой rpmbuild;

• 2.    технология Haser (для сборки в изолированном окружении);

• 3.    технология Gear (для сборки пакетов из репозитория Git).

Пакеты RPM создаются с помощью утилиты rpmbuild.

1. Утилита rpmbuild

2.

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

Утилита rpmbuild

Права для сборки

По умолчанию сборка rpm-пакетов запрещена суперпользователю (root) с целью повышения безопасности. Рекомендуется проводить сборку с правами непривилегированного пользователя, поскольку при сборке с правами root имеется высокая вероятность повреждения системы.

Ошибки при сборке

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

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

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

Также при ошибке «Installed (but unpackaged) file(s) found» это может означать, что в новой версии пакета появились новые файлы, отсутствующие ранее, и rpmbuild не

При ошибке сборки пакета RPM в Rosa все файлы, созданные командой rpmbuild, не удаляются — так же, как и при успешной сборке.

Чтобы быстро удалять эти файлы, можно создать скрипт cleanup.sh и поместить его в папку ~/rpmbuild/SPE CS.

Если пакет собран через rpm с ошибками, то все файлы, созданные командой rpmbuild, не удаляются — так же, как и при успешной сборке.

знает, что с ними делать.

Если эти файлы нужны, их необходимо добавить в секцию %files spec-файла.

Установка или обновление пакета

Установка пакета с помощью APT выполняется с помощью утилиты apt-get, используется и для обновления уже установленного пакета или группы пакетов. В этом случае apt-get дополнительно проверяет, не обновилась ли версия пакета в репозитории по сравнению с установленным в системе.

Установка пакета выполняется командой:

dnf install <имя_пакета>

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

Осуществляетс я с помощью менеджера DNF командой sudo dnf install <имя_пакета>

Установка пакета:

rpm    install

имя_пакета

Обновления пакета:

• a)     С

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

rpm    -Uvh

имя_пакета

• b)     Без

принудительн ой установки: rpm     -Fvh

имя_пакета

Обновление всех установленны х пакетов:

rpm -U или rpm -F

Необходимость удаления файлов предыдущей версии

При сборке новой версии     RPM-

пакета в ОС ALT не   обязательно

удалять предыдущие файлы, так как для обновления

можно

использовать команду  apt-get,

которая проведёт сравнение системы       с

репозиторием  и

удалит устаревшие пакеты, установив новые версии.

В большинстве случаев удалять предыдущие версии      не

требуется.

Однако,   при

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

проблемы   с

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

установкой новой.

При    сборке

новой   версии

RPM-пакета для Rosa     Linux

рекомендуется удалять предыдущие файлы.

Удаление прошлых версий пакетов    в

RPM    не

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

резервную копию старой его   версии.

Однако принудительн ое  удаление

пакета    без

учёта зависимостей может поломать работу других пакетов в ОП.

Удаление установленного пакета

Для    удаления

пакета используется команда   apt-get

remove     имя_

пакета. Для того

чтобы        не

нарушать целостность системы,   будут

удалены  и  все

пакеты, зависящие от удаляемого.

В случае удаления пакета,  который

Для  удаления

пакета используется следующая команда:

dnf    remove

<имя_пакета>

Для того чтобы не   нарушать

целостность системы, будут удалены и все пакеты,

Для  удаления

RPM-пакетов в Rosa     Linux

можно использовать инструмент urpme.

Также     для

удаления пакетов      в

дистрибутиве ROSA платформы 2021.1 и новее можно

Удаление пакета: rpm -e имя_пакета

относится      к

базовым

компонентам системы,   apt-get

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

зависящие  от

удаляемого.

использовать пакетный менеджер dnf.

Внутри spec-файла

Name – базовое имя пакета

Выбирается, исходя из названия главного бинарного пакета.

Имя      не

должно содержать пробелов, табуляций и символов новой строки. Однако, допустимо использовать дефис.

Version – номер версии программного обеспечения

Версия upstream-кода.

Release

Должно иметь вид в простых случаях — altN, а в

сложных — altN[с уффикс].

Увеличивается с каждой новой сборкой пакета, которая может быть связана с применением дополнительны х       патчей,

изменениями внесёнными в spec-файл    и

даже тривиальным

Как правило, при первой сборке конкретной версии пакета значение устанавливается равным 1 и увеличивается на единицу с каждой новой сборкой пакета. После цифры указывают суффикс макросом %{?dist}

обновлением пиктограммы.

Summary     –

краткое описание пакета

Значение тэга Summary должно начинаться с заглавной буквы. В конце Summary не должно быть точки

Для задания национальны х описаний

License

Лицензия должна быть указана в точности так, как сформулировано в upstream-пакете

Лицензия, под которой распространяется программа (обычно указано в самом пакете). Раньше в ходу был также тег Copyright, но сейчас он не используется.

URL

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

%description

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

Source

Если      сборка

производится без использования gea r,                  то

в Source настоятел ьно рекомендуется указывать действующий.

Исходные тексты, тарболы, просто файлы.

Рекомендуется указывать.

Раздел подготовки   к

сборке (prep)

%prep

%setup

распаковывает

исходный    код

перед

компиляцией.

%prep

Команды  для

подготовки программного обеспечения к сборке, например, распаковка архива, указанного в Source или So urce0.

%prep

%setup -q -a 1

Это встроенный макрос, который выполняет следующие действия:

переходит в дерево сборки;

распаковыва ет исходный

%prep

%setup -q

код      (-q

означает, что распаковка сопровожда ется минимальн ым выводом информации );

изменяет владельца и права доступа   к

файлам   с

исходным кодом.

%patch0 -p1

Макрос, ответственный за применение патчей       к

исходникам.

Раздел сборки

%build

%configure

%make_build

%build

%configure

%make

Команды установки/копир ования  файлов

из   сборочного

каталога      в

псевдо-корневую директорию

%install

%install

%makeinstall

%files

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

Список файлов должен быть написан в spec-файле вручную. Он может быть создан из списка файлов,

Список должен быть исчерпываю щим,  чтобы

утилита точно знала, что  именно

созданных программой rpm в дереве каталога сборки.

пакет устанавливае т.

Spec-cleaner удаляет устаревшие  и

ненужные декларации — buildroot;

а        также

изменяет оформление использования

макросов и переменных %{ const}, %{macro }. Такие

%clean

автоматически очищает BuildRoot пакета (с помощью макроса %clean_buildroot). Таким образом, ручная очистка BuildRoot является ненужной

изменения производятся только     для

макросов     и

переменных, определенных в самом rpm (а точнее, перечисленных непосредственн о в скрипте).

Также    Spec

cleaner способен производить замену устаревших версий макросов    на

современные аналоги.

%clean

rm         -rf

$RPM_BUIL D_ROOT

Список изменений, произошедших в пакете   между

сборками разных  версий

или релизов %changelog

автоматически

подставляет    в

начало   каждой

секции %files и в начало   каждого

файла, включаемого   с

помощью %files -f,

директиву %defatt r со    значением

макроса %_defattr.

Таким   образом,

ручное

указание %defattr является

излишним.

В changelog'е вы указывает изменения в пакете по сравнению с предыдущей версией. Синтаксис его примерно следующий:

%changelog

* День недели Месяц День Год Имя <Почта> -2.4.8-4

- update desktop patch