Как создать rpm пакет в linux

Обновлено: 08.07.2024

Сперва давайте разберёмся, что должно быть в системе для сборки rpm-пакета. Обязательно должен быть установлен пакет rpm-build . Без него не будет доступна команда rpmbuild. Наряду с ним, по зависимостям поставится еще ряд пакетов, используемых при сборке. В зависимостях для сборки пакета в РОСЕ обычно не принято прописывать компилятор C/C++, по этому поводу рано или поздно вам понадобятся пакеты gcc и gcc-c++ Все остальные зависимости должен попросить сам пакет. Конечно бывают промахи, и в процессе сборки вы понимаете, что что-то упустили, но это обычно бывает довольно редко и не критично.

А что собственно из себя представляет RPM пакет? RPM-пакеты делятся на пакеты с исходниками - src.rpm и пакеты, готовые к установке - %.rpm . В src.rpm пакетах содержится исходный тарболл (исходник программы), какие-либо другие исходники, пачти и самый главный spec-файл, который управляет процессом сборки. Все эти файлы упакованы в cpio архив. Когда вы пытаетесь войти в src.rpm пакет при помощи файлового менеджера mc , вы его увидите. Также в пакете присутствует некоторые файлы с информацией.

Также вы можете встретить без исходного кода. Обычно их создают для проприетарных программ, которые нельзя включать в дистрибутив (исходников нет, а бинарник каким-то образом нужно переделать либо просто запрещено размещать на зеркалах дистрибутива лицензией). Внутри этого пакета находится обычно только spec-файл, а бинарник скачивается и, при необходимости, модифицируется, в процессе установки пакета (например, в post-скрипте, о котором речь пойдет ниже).

Что нужно сделать, чтобы можно было собирать пакеты из-под обычного пользователя? Первым делом нужно создать в своём домашнем каталоге файл директорию rpmbuild со следующей структурой:

Каталоги BUILD , RPMS , SOURCES , SPECS , SRPMS вам необходимо создать вручную, подкаталоги каталога RPMS должны создаться автоматически во время сборки в зависимости от архитектуры.

В РОСЕ не принято писать сборщика пакета и вендора в spec-файлах; эти значения выставляются автоматически системой сборки ABF. Также ABF автоматически подписывает собранные пакеты ключом соответствующего репозитория. Поэтому эти вопросы мы здесь затрагивать не будем.

Теперь давайте посмотрим что из себя представляет самый главный файл rpm-пакета, spec-файл. Для примера возьмём его из пакета stardict . Этот пакет хорошо подходит для обучения, так как в нем есть несколько тарболов (исходник программы, упакованный tar ’ом), получается несколько пакетов и есть такая вещь, как схемы. Обычно spec-файл имеет такое же имя, как и сам пакет ( stardict.spec ). Однако вы можете добавить версию пакета ( stardict-2.spec ), удобно если вы пытаетесь поддерживать несколько веток программ. Можно даже дать какое-нибудь другое название, однако это мягко говоря не удобно.

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

Spec-файл состоит из секций и шапки:

Summary — краткое описание пакета, Name — название, Version — версия, Release — релиз. Последним трем тегам соответствуют макроопределения % , % , % . Их часто используют в дальнейшем. Name и Version обычно совпадает с название тарбола. Если же они отличаются, то в принципе ничего страшного, но придётся в некоторых местах spec-файла действовать нестандартными методами. Если вы собираете пакет из cvs, svn и т. д., то рекомендуется в самом начале файла сделать макроопределение %define date 20070422 (именно в таком формате, сами догадайтесь почему) и тег Release определить следующим образом:

Далее, License — лицензия, под которой распространяется программа (обычно указано в самом пакете). Раньше в ходу был также тег Copyright, но сейчас он не используется. URL — сайт программы, Group — группа, в которую будет входить данный пакет. Обычно следует прикинуть на что этот пакет похож, и посмотреть группу похожего пакета. Придумывать группу самому не стоит, лучше посмотреть в список имеющихся.

В spec-файлах пакетов многих дистрибутивов вы также можете в заголовке встретить определение BuildRoot - каталога, в котором осуществляется сборка. В РОСЕ в этом определении нет необходимости, имя BuildRoot формируется автоматически.

BuildRequires — секция, в которую через запятую или через пробел прописываются пакеты, которые требуются для сборки нашей программы. Почерпнуть их можно из каких-нибудь файлов README и INSTALL (хотя там редко бывает что-то полезное по этому поводу), из процесса конфигурации (на данный момент обычно это скрипт configure ) и из самого процесса сборки (иногда configure что-нибудь пропустит и сборка остановится).

Requires — в эту секцию записываются пакеты или файлы(!), которые будет требовать данный пакет при установке. При сборке в зависимости автоматически пропишутся все библиотеки, которые наш пакет потребует, но вы также можете указать пакеты вручную. Rpm также автоматически прописывает зависимости perl, python, mono и некоторые другие (все эти зависимости прописываются не в spec-файл разумеется, а в сам пакет). Если вам не нужно, чтобы зависимости прописывались автоматически, следует прописать в spec-файл новый тег AutoReq: no. Обычно его прописывают при сборки проприетарных программ, так как rpm добавляет внутренние зависимости из собираемой программы.

В нашем примере используются конструкции Requires(post) и Requires(postun) для зависимостей в скриптах установки и удаления. В принципе достаточно и простого Requires . Здесь особенно нечего комментировать. Просто самому StarDict в процессе работы эти зависимости не нужны. Нужны они только при инсталляции и удалении.

Есть ещё несколько полезных тегов, которые здесь не используются.

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

— удаление указанных пакетов при установки текущего пакета. Как бы говорится, что данный пакет замещает собой указанные (по функциональности, по набору файлов и т. п.). Можно использовать конструкцию название < . Тут вы должны сами понимать, что к чему.

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

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

— обычно или не указывается совсем или равняется 0. Суть этого параметра вот в чем. Пусть всё наш же пакет stardict имеет версию 2.4.8, а также есть более старый 2.4.5. Так вот если % у stardict 2.4.5 будет 1, а у 2.4.8 - 0, то пакет 2.4.5 будет всегда новее, чем 2.4.8 . О чём при установки вам RPM и скажет. Этот параметр удобен, если вы хотите откатиться на предыдущую версию (разумеется, если вы это все выкладываете в публичный репозиторий и хватаете все через urpmi или rpmdrake . Для «домашних» нужд подойдёт параметр к rpm --force ). Если определён тег Epoch: 0 , то пакет будет иметь приоритет перед пакетом с непоределённым тегом Epoch .

— архитектура, под которую будет собираться наш пакет. Если эта опция не указана, то пакет соберётся под текущую архитектуру. Обычно эту опцию указывают для того, чтобы собирать пакет архитектуры noarch, то есть пакет, в котором нет бинарников.

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

На этом шапка заканчивается и начинаются отдельные секции.

Описание главного пакета, того, у которого будет имя %

Описание второго пакета

Секция %prep в ней начинается подготовка к сборке. %setup распаковывает исходники. Опция -q не показывает вывод распаковывания архива. Опция -a1 используется для распаковки % , второго тарбола внутрь(!) каталога первого тарбола. Соответственно цифра указывает на номер SOURCE. Ещё иногда используется параметр -b, тогда второй тарбол распаковывается в тот же каталог, что и первый. Соответственно если у нас один тарбол, то опции -a, -b не используются.

Если у вас первый каталог в тарболе имеет отличное от %-% название, то rpm не сможет войти автоматом в этот каталог. В таком случае следует немного изменить %setup . Если в архиве stardict-2.4.8.tar.bz2 первый каталог имеет название, например, просто stardict , то выглядеть это будет так:

При помощи %patch накладываются патчи. Если вы делали патч, как мы писали выше, то у вас всегда будет параметр -p1. Также часто используют параметр -b .название_патча , для создания резервной копии.

Секция %build , именно здесь происходит сборка пакета. Обратите внимание на pushd и popd . Этими командами мы переходим и выходим из каталога второго тарбола. Именно он будет корневым каталогом после pushd . После команды popd мы вернёмся в каталог первого тарбола. Соответственно если у вас один исходник, то не нужно использовать эти команды.

Так как у нас две программы в одном пакете, то мы выполняем два раза концигурацию %configure и два раза make . Если пакет конфигурируется при помощи autotools , то макросом %configure запускается скрипт configure из корня распакованного тарбола. У него обычно бывает много параметров, их можно посмотреть из командной строки при помощи ./configure --help . После %configure вы можете указать нужные вам параметры. Заметьте, что вызов %configure и ./configure отличаются. В первом случае конфигуратору будут переданы правильные каталоги для инсталляции (а также стандартные параметры), во втором - каталоги по умолчанию.

После успешной конфигурации идет сборка, а именно макрос %make , вызывающий одноименную команду с некоторыми дополнтельными параметрами (в частности, на многопроцессорных машинах используется параллельная сборка - опиця -j).

Если пакет не использует autotools , то %configure , а может и %make использовтаь не нужно, для сборки прочтите файл README и INSTALL. В РОСЕ есть макросы и на другие случаи жизни - например, %cmake для одноименного инструмента сборки.

Когда сборка успешна закончена, в действие вступает секция %install .

% %find_lang , поиск файлов локализации. Параметром у неё является название файлов, которые будут лежать после установки в каталоге %/usr/share/locale/*/LC_MESSAGES/*.mo . Обычно оно соответствует % . Если это не так, пишите другое имя.

Секции для установочных скриптов. Вообще их бывает несколько. %pre — выполняется перед установкой, %post — после установки, %preun — перед удалением, %postun — после удаления. В нашем примере при удалении удаляются схемы Gconf. Здесь мы предполагаем, что в пакете только одна схема и ее имя совпадает с именем пакета. Обратите внимание, что для удаления схем мы вызываем специальный макрос; этот макрос раскрывается rpmbuild РОСЫ в набор необходимых команд оболочки Shell, которые, собственно, и удаляют схему. Установка схем при установке пакета выполняется автоматически за счет файловых триггеров RPM.

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

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

Для определения каталогов используются специальные макроопределения.

% — /usr
% — /etc
% — /usr/bin
% — /usr/share
% — /usr/lib или /usr/lib64 в зависимости от разрядности системы
% — соответственно /lib или /lib64
% — /usr/libexec
% — / usr/unclude
% — /usr/share/man
% — /usr/sbin
% — /var .
% — /usr/lib/systemd

%doc помечает файлы как документацию. Третья строка копирует указанные файлы в каталог %/doc/%-% . По умолчанию файлы в rpm пакете будут иметь владельцем root’а, а права доступа у низ будут такие же, как и в процессе установки. Если это необходимо поменять, то воспользуйтсь конструкцией %defattr .

Далее просто перечисляются файлы.

Тоже самое для пакета stardict-tools . Если бы он назывался tools-stardict , то %files выглядел бы так:

Последнее, что идёт в spec-файле, это %changelog . В changelog’е вы указывает изменения в пакете по сравнению с предыдущей версией. Синтаксис его примерно следующий.

Макроопределения

Теперь пора познакомиться поближе с макросами и переменными. Допустим, мы собираем пакет из SVN, в данном случае в релиз обычно включается дата ревизии. В самом начале spec-файла нужно определить переменную date:

Как мы видим, за определение переменных отвечает макроопределение %define . Теперь в любом месте spec-файла мы можем использовать нашу переменную в виде % (скобки не обязательны, но в РОСЕ принято брать в скобки переменные, и не брать - макроопределения; так их проще различать). Например, определение основных параметров будет выглядеть примерно так:

Обратите внимание, что перед датой стоит 0., а после даты - число, которое и увеличивается при необходимости поднять релиз. Зачем так сделано? Когда наконец выйдет окончательная версия (в нашем случае - 0.5), ревизию можно будет убрать, а в релиз прописать просто 1. При этом литерально 1 больше, чем любая строка, начинающаяся на 0, и пакет будет считаться более новым, чем предварительные пакеты, собиравшиеся на основе ревизий SVN.

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

или просто %if без %else . Суть проста, если условие стоящее при %if истина, то выполняется действие1 , в противном случае выполняется действие2 .

Допустим, мы опять же собираем что-нибудь из SVN. Обычно внутри архива, если он из SVN, вместо каталога %-% указывают просто % (архив sim-0.9.5.tar.bz2 внутри имеет каталог sim , так как финального релиза sim 0.9.5 не существует. Конечный же релиз будет иметь первым каталогом sim-0.9.5 ). Чтобы всякий раз не переписывать spec-файл, можно сделать следующие макроопределения:

Если переменная svn не определена, то будет выполняться часть сценария после %else . Можно также использовать более строгое условие (не забудьте про кавычки):

Внутри всех секций spec-файла мы можем использовать любые команды Linux, без каких либо «наворотов», а вот в шапке файла не всё так просто. Например, нам нужно определить версию firefox для пакета (допустим epiphany) и прописать ее в секцию Requires: . Выглядеть это будет следующим образом:

Ещё одним популярным макроопределение является конструкция %ifarch .. %endif . Если архитектура соответствует указанной после %ifarch , то выполняется какое либо действие. Архитектуры бывают i386, i486, i586, i686, i?86, x86_64, и понятное дело некоторые другие, с которыми вы наверно не столкнётесь.

Как уже отмечалось выше во всех секциях spec-файла вы можете использовать любые команды Shell, включая for, while, if и др.

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

Теперь перейдём непосредственно к сборке пакета. Исходники и патчи должны лежать в каталоге SOURCES , а spec файл в каталог SPECS . После этого нужно отдать команду:

После этого пакет соберётся (или не соберётся, а вывалится с ошибками), и в подкаталогах каталога RPMS появятся бинарные пакеты, а в каталоге SRPMS появится исходник.

Добавить в секцию %files макроопределение

Добавить в начало spec-файла макроопределение

Если необходимо собрать только бинарник или только исходник, то вместо -ba следует использовать -bb и -bs соответственно. Из полезных параметров rpmbuild можно отметить -clean (удалить весь мусор), -rmsource (удалить исходники из каталога SOURCE ) и -target=архитектура (собрать пакет под конкретную архитектуру).

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

Сборка RPM пакета из уже установленного в системе

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

Для решения этой проблемы следует воспользоваться утилитой rpmrebuild. Эта написанная на bash утилита доступна в contrib-репозитории РОСЫ.

Работать с ней крайне просто. Нужно отдать всего лишь команду:

Если какой-либо файл был изменён, то вам об этом сообщат, но процесс сборки не прервётся.

Rpmrebuild обладает огромным количеством параметров, например, вы можете изменять release пакета, changelog, скрипты, секции Requires, описания пакета и многое другое. Можете даже просто напросто изменить spec-файл, который скрипт сгенерирует сам. Он правда будет немного страшный, но это все же лучше, чем ничего.

В данной статье будет подробно описан процесс создание rpm пакетов и организация репозитория. Прошу всех, кому интересна данная тема, пройти под кат.

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

Наш сервис начинается с момента установки на него операционной системы. Естественно, что для сборки rpm пакетов мы выбираем rhel дистрибутив. В данном случае, был выбран CentOS 7.

Создадим директорию, где будет лежать образ и перейдем в нее:

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

или посредством torrent`а с помощью программы aria2, которую для начала установим:

Проверить образ

Скачаем ключ для CentOS 7:

Посмотрим на ключ и импортируем его:

Проверим подпись файла, с контрольной суммой образа:

Как мы видим — все отлично и теперь можем проверить сам образ на целостность:

Запись образа на носитель

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

Запись образа на диск

Для записи данного образа, нам понадобится двухсторонний DVD. Допустим мы его нашли и записываем, установив предварительно wodim:

Запись образа на флешку

Двухсторонний DVD это как то архаично, так что возьмем флешку на 16 гб и запишем образ на нее, но прежде /dev/sda тут — это флешка, а у Вас она может быть другой. Смотри команду fdisk:

Если status=progress не поддерживается, то по старинке:

а можно воспользоваться pv:

Установка

Как поставить Centos 7, решать Вам, тут и за RAID подумать можно и за LVM и много чего еще,
я ставил минимальный пакет.

Процесс установки можно посмотреть в этом ролике.

После установки системы, нам необходимо настроить наш сервер.

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

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

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

Для того чтобы комфортно и безопасно управлять сервером настроим SSH.

Безопаснее пользоваться ключами, по этому мы и создадим себе ключи для доступа к серверу на своем рабочем компьютере:

и добавим ключ на сервер:

Необходимо еще закрутить гайки в самой службе. Создадим копию файла конфигурации и приступим к редактированию:

В файле стоит добавить/изменить/раскомментировать следующие строки:

Межсетевой экран

Важно ограничить доступ к нашему серверу. По этой причине настроим межсетевой экран:

Подготовим саму площадку для сборки. Стоит отметить, что вернее всего сборку производить на отдельном виртуальном хосте, активно используя технологию snapshot'ов, но тут я опишу все в едином целом. Так же для сборки нужно выделить отдельного пользователя, не являющемся администратором (т.е. sudo ему недоступно).

Создание директорий

Создаем необходимые директории:

Настройка PGP подписи

Наши пакеты, которые мы соберем, необходимо подписать, что будет обеспечивать целостность и достоверность.

Ключ будем использовать свой или если его нет, то создадим. Создавать ключ стоит на своем рабочем компьютере.

Создадим ключ, если его у нас нет:

Сохраняем наш приватный ключ:

Создадим ключ для отзыва:

Экспорт открытого ключа на keyserver:

Теперь ключ можно и импортировать на наш сервер:

Смотрим где находится gpg утилита:

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

Создаем репозиторий

Теперь организуем сам репозиторий.

Создадим директорию, где будем хранить пакеты:

Экспортируем ключ в репозиторий:

Создаем сам репозиторий и подписываем метаданные:

Пакет для репозитория

Собираем пакет для автоматической установки репозитория в систему.

Файл репозитория для yum:

Экспортируем ключ для пакета:

Собираем все в архив:

Создаем SPECS файл для пакета:

На этом этапе нас спросят пароль от нашего PGP ключа.

Копируем созданный пакет в репозиторий и обновляем его:

Не забываем подписать метаданные:

Теперь установим наш репозиторий в систему:

После установки должен появиться репозиторий chelaxe и PGP ключ:

Самое важное тут это SPEC файлы, расписывать о них не стану, но предоставлю ряд ссылок:

и одна полезная команда:

она отобразит готовые макросы для сборки.

Теперь соберем, для примера, что нибудь полезное. Собирать будем tmux — терминальный мультиплексор, без которого работать мне не комфортно. Стоит отметить tmux есть в base репозитории CentOS 7, но версия там 1.8, а мы соберем 2.7. Так же у пакета из base репозитория есть зависимость libevent, мы же соберем tmux со статическими библиотеками последних версий.

Готовим исходники

Скачиваем исходники tmux и необходимых библиотек:

Экспортируем GPG ключи для проверки исходников:

Подготовим файл конфигурации tmux:

Готовим SPEC файл

Этот файл будет интереснее предыдущего SPEC файла:

Сборка

Собираем пакет и добавляем его в репозиторий:

Не забываем подписать метаданные:

Смотри что и как получилось:

Установка и запуск

Устанавливаем наш пакет:

Запускаем tmux и радуемся:

Собирать будем fbida — комплект приложений для просмотра изображений в консоли. Данный пакет не нашел под Centos 7.

Готовим исходники

Скачиваем исходники fbida:

Экспортируем GPG ключи для проверки исходников:

Готовим SPEC файл

В этом SPEC файле будет больше зависимостей:

Сборка

Собираем пакет и добавляем его в репозиторий:

Не забываем подписать метаданные:

Установка и запуск

Устанавливаем наш пакет:

Настройка

Первым делом настроем наш Apache:

Далее необходимо добавить/изменить/раскомментировать следующие строки:

Запускаем службу и прописываем ее в автозапуск:

Настраиваем наш репозиторий:

Т.к. в Centos 7 у нас Apache 2.4.6, а не 2.4.8, то параметры Диффи-Хеллмана необходимо вшить в сертификат:

Проверим конфигурацию и перечитаем конфигурацию:

Сертификат от Let's Encrypt

Пока у нас свой сертификат и это не красиво, так что получим сертификат от Let's Encrypt:

Строку Include /etc/letsencrypt/options-ssl-apache.conf закомментируем.

Тут стоит напомнить о необходимости добавить файл с параметрами Диффи-Хеллмана в конец сертификата:

И изменим соответственно строку в конфигурации:

Проверим конфигурацию и перечитаем конфигурацию:

Есть еще одна проблема. Для обновления сертификата добавим запись в крон:

Файлы .htaccess

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

и AllowOverride смените на All . Так же добавьте:

для исключения в отображении на сайте.

Для vsftpd можно использовать опции:

А вообще смените стандартное имя .htaccess на другое с помощью параметра AccessFileName :

Тут можно используя модуль mod_autoindex Apache настроить внешний вид. Завернуть в noscript тег и используя html5, css3, javascript, jquery, bootstrap, backbone, awesome сделать конфетку, как это сделал я:

Вот что будет при использовании в браузере без поддержки javascript или с отключенным:

Сами файлы web интерфейса нужно будет скрыть как от vsftpd так и от демонстрации на сайте, делается аналогичными способами что и для сокрытия .htaccess файла.

Настроить внешний вид листинга через mod_autoindex или в nginx:

Запускаем службу и прописываем ее в автозапуск:

В случае использования .htaccess файла — продублируйте, чтобы файл был надежно защищен от доступа по ftp:

Установка CheckInstall on Linux.

Чтобы установить Checkinstall на Debian/Ubuntu и остальных debian-оподобных ОС, выполните:

Чтобы установить Checkinstall в дистрибутивах основанных на Red Hat, вам нужно будет скачать встроенных .rpm в Checkinstall, можете использовать мой.

Для начала пробуем его найти в ОС:

Если покажет что есть пакет, то его можно установить:

Или качаем пакет:

После установки Checkinstall, вы можете использовать следующий формат чтобы собрать пакет для конкретной ОС:

Сборка RPM или DEB пакета с CheckInstall

Первое что нужно сделать, так это скачать исходный код с официального сайта. Я привык сохранять все архивы в /usr/local/src. Скачиваем исходный код программы и распаковываем ее, и переходим в папку с кодом для дальнейших действий:

Вот команды, чтобы собрать пакет Htop:

2. Вы можете ввести краткое описание пакета, а затем нажмите Enter два раза.

checkInstall Unix/Linux пример

После чего Checkinstall создаст .rpm или .deb пакет автоматически, в зависимости от вашей системы Linux.

На CentOS 7 выглядит это так:

На Debian 7 выглядит это так:

Опции Checkinstall

*Выбор тип пакета*

-S
Собрать пакет для Slackware.

*Опции для установки собранных пакетов*

*Опции для скриптов*

*Опции выводимой информации*

-d<0|1|2>
Установить уровни для debug.

-si
Запустить интерактивную установку команды.

-ss
Запустите интерактивный скрипт установки для Slackware.

* Параметры настройки пакета *

* Параметры очистки *

Сборка RPM - быстрый старт

Подготовка к сборке и обзор spec-файла

Сперва давайте разберёмся, что должно быть в системе для сборки rpm-пакета. Обязательно должен быть установлен пакет rpm-build. Без него не будет доступна команда rpmbuild. Наряду с ним, по зависимостям поставится еще ряд пакетов, используемых при сборке. В зависимостях для сборки пакета в РОСЕ обычно не принято прописывать компилятор C/C++, по этому поводу рано или поздно вам понадобятся пакеты gcc и gcc-c++ Все остальные зависимости должен попросить сам пакет. Конечно бывают промахи, и в процессе сборки вы понимаете, что что-то упустили, но это обычно бывает довольно редко и не критично.

А что собственно из себя представляет RPM пакет? RPM-пакеты делятся на пакеты с исходниками - src.rpm и пакеты, готовые к установке - %.rpm . В src.rpm пакетах содержится исходный тарболл (исходник программы), какие-либо другие исходники, пачти и самый главный spec-файл, который управляет процессом сборки. Все эти файлы упакованы в cpio архив. Когда вы пытаетесь войти в src.rpm пакет при помощи файлового менеджера mc, вы его увидите. Также в пакете присутствует некоторые файлы с информацией.

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

Собирать пакеты можно из-под любого пользователя. Делать это из-под root'а не рекомендуется, т.к. есть вероятность, что корнем для секции инсталляции окажется каталог / и тогда команда rm -rf % уничтожит все на свете. Также бывает, что «кривые» пакеты не правильно выполняют инсталляцию, и ставятся не во временный каталог, а прямо куда-нибудь в % (/usr) . Часть файлов будет потеряна, хотя на работоспособности пакета на этой машине понятное дело это не скажется.

Каталоги BUILD, RPMS, SOURCES, SPECS, SRPMS вам необходимо создать вручную, подкаталоги каталога RPMS должны создаться автоматически во время сборки в зависимости от архитектуры.

Теперь давайте посмотрим что из себя представляет самый главный файл rpm-пакета, spec-файл. Для примера возьмём его из пакета stardict. Этот пакет хорошо подходит для обучения, так как в нем есть несколько тарболов (исходник программы, упакованный tar’ом), получается несколько пакетов и есть такая вещь, как схемы. Обычно spec-файл имеет такое же имя, как и сам пакет ( stardict.spec ). Однако вы можете добавить версию пакета ( stardict-2.spec ), удобно если вы пытаетесь поддерживать несколько веток программ. Можно даже дать какое-нибудь другое название, однако это мягко говоря не удобно.

Spec-файл состоит из секций и шапки:

License — лицензия, под которой распространяется программа (обычно указано в самом пакете). Раньше в ходу был также тег Copyright, но сейчас он не используется. URL — сайт программы, Group — группа, в которую будет входить данный пакет. Обычно следует прикинуть на что этот пакет похож, и посмотреть группу похожего пакета. Придумывать группу самому не стоит, лучше посмотреть в список имеющихся.

Source* — исходные тексты, тарболы, просто файлы. В данном примере идут два тарбола с разными программами, что делает сборку намного сложнее. Обычные файлы, например, конфигурации, могут просто копироваться в секции %%install при помощи команды install . У нее простой синтаксис, install -m маска_как_у_chmod что куда. При помощи нее можно также создавать каталоги. В нашем примере она не используется, но подробнее про неё можно почитать в man.

В нашем примере используются конструкции Requires(post) и Requires(postun) для зависимостей в скриптах установки и удаления. В принципе достаточно и простого Requires. Здесь особенно нечего комментировать. Просто самому StarDict в процессе работы эти зависимости не нужны. Нужны они только при инсталляции и удалении.

Есть ещё несколько полезных тегов, которые здесь не используются.

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

— удаление указанных пакетов при установки текущего пакета. Как бы говорится, что данный пакет замещает собой указанные (по функциональности, по набору файлов и т. п.). Можно использовать конструкцию название <. Тут вы должны сами понимать, что к чему.

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

— обычно или не указывается совсем или равняется 0. Суть этого параметра вот в чем. Пусть всё наш же пакет stardict имеет версию 2.4.8, а также есть более старый 2.4.5. Так вот если % у stardict 2.4.5 будет 1, а у 2.4.8 - 0, то пакет 2.4.5 будет всегда новее, чем 2.4.8. О чём при установки вам RPM и скажет. Этот параметр удобен, если вы хотите откатиться на предыдущую версию (разумеется, если вы это все выкладываете в публичный репозиторий и хватаете все через urpmi или rpmdrake. Для «домашних» нужд подойдёт параметр к rpm --force ). Если определён тег Epoch: 0, то пакет будет иметь приоритет перед пакетом с непоределённым тегом Epoch.

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

На этом шапка заканчивается и начинаются отдельные секции.

Описание главного пакета, того, у которого будет имя %

Здесь мы создаём новый пакет, название которого будет %-tools. Если нужно обозвать пакет совсем по другому, то следует сделать, например, так: %package -n tools-stardict. Версия нового пакета берётся из заданного тега Version. Обратите внимание на Requires. В нём прописана зависимость на главный пакет stardict. Если бы он имел % , то необходимо было бы обязательно указать Requires: %-%:%-% . Иначе вам просто не удастся установить это пакет.

Описание второго пакета

Если у вас первый каталог в тарболе имеет отличное от %-% название, то rpm не сможет войти автоматом в этот каталог. В таком случае следует немного изменить %setup. Если в архиве stardict-2.4.8.tar.bz2 первый каталог имеет название, например, просто stardict, то выглядеть это будет так:

Секция %build, именно здесь происходит сборка пакета. Обратите внимание на pushd и popd. Этими командами мы переходим и выходим из каталога второго тарбола. Именно он будет корневым каталогом после pushd. После команды popd мы вернёмся в каталог первого тарбола. Соответственно если у вас один исходник, то не нужно использовать эти команды.

Так как у нас две программы в одном пакете, то мы выполняем два раза концигурацию %configure и два раза make. Если пакет конфигурируется при помощи autotools, то макросом %configure запускается скрипт configure из корня распакованного тарбола. У него обычно бывает много параметров, их можно посмотреть из командной строки при помощи ./configure --help. После %configure вы можете указать нужные вам параметры. Заметьте, что вызов %configure и ./configure отличаются. В первом случае конфигуратору будут переданы правильные каталоги для инсталляции (а также стандартные параметры), во втором - каталоги по умолчанию.

После успешной конфигурации идет сборка, а именно макрос %make, вызывающий одноименную команду с некоторыми дополнтельными параметрами (в частности, на многопроцессорных машинах используется параллельная сборка - опиця -j).

Если пакет не использует autotools, то %configure, а может и %make использовтаь не нужно, для сборки прочтите файл README и INSTALL. В РОСЕ есть макросы и на другие случаи жизни - например, %cmake для одноименного инструмента сборки.

Когда сборка успешна закончена, в действие вступает секция %install.

%%find_lang, поиск файлов локализации. Параметром у неё является название файлов, которые будут лежать после установки в каталоге %/usr/share/locale//LC_MESSAGES/.mo. Обычно оно соответствует % . Если это не так, пишите другое имя.

Во многих spec-файлах вы можете заметить выполнение команды rm -rf % или rm -rf $RPM_BUILD_ROOT в самом начале секции %install, а также секцию %clean с такими же строками. В современной РОСЕ в этом нет необходимости, такая зачистка выполняется автоматически.

Для определения каталогов используются специальные макроопределения.

% — /usr
% — /etc
% — /usr/bin
% — /usr/share
% — /usr/lib или /usr/lib64 в зависимости от разрядности системы
% — соответственно /lib или /lib64
% — /usr/libexec
% — /usr/unclude
% — /usr/share/man
% — /usr/sbin
% — /var.
% — /usr/lib/systemd

Далее просто перечисляются файлы.

Тоже самое для пакета stardict-tools. Если бы он назывался tools-stardict, то %files выглядел бы так:

Последнее, что идёт в spec-файле, это %changelog. В changelog’е вы указывает изменения в пакете по сравнению с предыдущей версией. Синтаксис его примерно следующий.

Как мы видим, за определение переменных отвечает макроопределение %define. Теперь в любом месте spec-файла мы можем использовать нашу переменную в виде % (скобки не обязательны, но в РОСЕ принято брать в скобки переменные, и не брать - макроопределения; так их проще различать). Например, определение основных параметров будет выглядеть примерно так:

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

или просто %if без %else. Суть проста, если условие стоящее при %if истина, то выполняется действие1 , в противном случае выполняется действие2 .

Допустим, мы опять же собираем что-нибудь из SVN. Обычно внутри архива, если он из SVN, вместо каталога %-% указывают просто % (архив sim-0.9.5.tar.bz2 внутри имеет каталог sim, так как финального релиза sim 0.9.5 не существует. Конечный же релиз будет иметь первым каталогом sim-0.9.5 ). Чтобы всякий раз не переписывать spec-файл, можно сделать следующие макроопределения:

Если переменная svn не определена, то будет выполняться часть сценария после %else. Можно также использовать более строгое условие (не забудьте про кавычки):

Внутри всех секций spec-файла мы можем использовать любые команды Linux, без каких либо «наворотов», а вот в шапке файла не всё так просто. Например, нам нужно определить версию firefox для пакета (допустим epiphany) и прописать ее в секцию Requires:. Выглядеть это будет следующим образом:

Обратите внимание на то, что внешняя команда выполняется в %() (почти, как в bash - $()) и в spec-файле необходимо ставить два знака % в параметрах. Таким образом можно вызывать любые команды Linux, например, для определения версии ядра.

Ещё одним популярным макроопределение является конструкция %ifarch .. %endif. Если архитектура соответствует указанной после %ifarch, то выполняется какое либо действие. Архитектуры бывают i386, i486, i586, i686, i?86, x86_64, и понятное дело некоторые другие, с которыми вы наверно не столкнётесь.

Теперь перейдём непосредственно к сборке пакета. Исходники и патчи должны лежать в каталоге SOURCES, а spec файл в каталог SPECS. После этого нужно отдать команду:

Добавить в начало spec-файла макроопределение

Если необходимо собрать только бинарник или только исходник, то вместо -ba следует использовать -bb и -bs соответственно. Из полезных параметров rpmbuild можно отметить -clean (удалить весь мусор), -rmsource (удалить исходники из каталога SOURCE) и -target=архитектура (собрать пакет под конкретную архитектуру).

Сборка RPM пакета из уже установленного в системе

Работать с ней крайне просто. Нужно отдать всего лишь команду:

Если какой-либо файл был изменён, то вам об этом сообщат, но процесс сборки не прервётся.

Читайте также: