Linux rpm что это

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Вам пакет нужен? Нет, я со своим.

Есть несколько способов откуда можно взять пакеты RPM: CD/DVD с программным обеспечением, CentOS Mirror, RedHat (нужен аккаунт) или любые открытые сайты репозитория.

В RPM используется несколько основных режимов команд: Install (используется для установки любого пакета RPM), Remove (используется для удаления, стирания или деинсталляции пакета), Upgrade (используется для обновления существующего пакета), Query (используется для запроса пакета) и Verify (используется для проверки пакетов RPM).

Рассмотрим это на примере. У нас есть пакет, и теперь посмотрим, что мы можем с ним делать.

Установка

Как узнать информацию о пакете RPM без установки?

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

Как установить RPM пакет?

Мы можем использовать параметр -ivh для установки определенного пакета, как показано ниже.

Как проверить установленный пакет RPM?

Мы можем использовать параметр -q с именем пакета, и он покажет, установлен ли пакет или нет.

Как вывести список всех файлов для определенного установленного пакета RPM?

Мы можем перечислить все файлы установленных пакетов rpm, используя опцию -ql с командой rpm.

Как вывести список недавно установленных пакетов RPM?

Мы можем использовать параметр -qa с параметром —last, в котором будут перечислены все недавно установленные пакеты rpm.

Как установить RPM пакет без зависимостей?

Мы можем использовать параметры -ivh с параметром —nodeps для проверки отсутствия зависимостей, чтобы установить конкретный пакет без зависимостей, как показано ниже.

Как заменить установленный пакет RPM?

Мы можем использовать параметры -ivh –replacepkgs для замены установленного пакета.

Удаление

Как удалить пакет RPM?

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

Обновление

Как обновить установленный пакет RPM?

Для обновления пакета мы используем параметры -Uvh

Запрос

Как запросить все установленные пакеты?

Мы можем использовать параметры -a вместе с q для запроса всех установленных пакетов на сервере.

Как запросить конкретный пакет?

Мы можем использовать команду grep, чтобы узнать, установлен ли конкретный пакет или нет.

Как запросить файл, который принадлежит пакету RPM?

Чтобы узнать к какому пакету RPM относится файл /usr/lib64/libGeoIP.so.1.5.0. используем следующую команду.

Проверка

Как получить информацию для конкретного пакета?

Мы можем использовать параметры -i вместе с q, чтобы получить информацию для конкретного пакета, как показано ниже.

Как проверить RPM пакет?

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

Как проверить все пакеты RPM?

Мы можем проверить все установленные пакеты rpm, используя опцию -Va

Полезно?

Почему?

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

😍 Полезные IT – статьи от экспертов раз в неделю у вас в почте. Укажите свою дату рождения и мы не забудем поздравить вас.

Источник

Установка rpm пакетов в Linux

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

Последний встречается немного реже, но если вы используете дистрибутив на базе Red Hat Enterprice Linux, вам нужен именно этот формат пакетов. Также в сети часто можно найти библиотеки и другие компоненты, которых нет в репозиториях в виде пакетов. Раньше мы уже рассматривали установку deb пакетов в Ubuntu. А в этой статье будет подробно разобрана установка rpm пакетов в linux.

Что такое RPM?

Установка RPM пакетов в Linux

Давайте сначала рассмотрим синтаксис самой утилиты rpm:

Утилита может работать в одном из режимов:

Рассмотрим только самые интересные опции программы, которые понадобятся нам в этой статье:

Теперь, когда вы уже имеете представление как работать с этой утилитой, может быть рассмотрена установка rpm пакета в Linux. Самая простая команда установки будет выглядеть вот так:

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

Также вы можете включить отображение статус бара в процессе установки:

Чтобы проверить установлен ли пакет, нам уже нужно использовать режим запроса:

Также сразу можно удалить пакет, если он не нужен:

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

Для автоматической загрузки зависимостей во время выполнения установки rpm linux нужно использовать пакетный менеджер дистрибутива. Рассмотрим несколько команд для самых популярных RPM дистрибутивов. В RedHat и других дистрибутивах, использующих Yum используйте такую команду:

Первая опция отключает проверку GPG ключа, а вторая говорит, что мы будем выполнять установку локального пакета. В Fedora, с помощью dnf все делается еще проще:

sudo dnf install имя_пакета.rpm

Пакетный менеджер Zypper и OpenSUSE справляются не хуже:

sudo zypper install имя_пакета.rpm

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

Установка RPM файла в GUI

Если вы используете OpenSUSE, то это делается очень просто. Универсальный конфигуратор системы YaST, кроме всего прочего позволяет установить rpm пакеты. Вы можете сделать это с помощью файлового менеджера, выбрав пункт контекстного меню для файла открыть с помощью Yast или выполнив команду:

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

Выводы

Теперь вы знаете как выполняется установка rpm файла в Linux. На самом деле это очень просто и даже существует не только один способ, а целых несколько. Хотя графических утилит здесь немного меньше чем в Ubuntu. Но консольных утилит полностью хватает. Если у вас остались вопросы, спрашивайте в комментариях!

Источник

Команда RPM в Linux

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

Установка, обновление и удаление пакетов RPM

Вы всегда должны предпочитать использовать yum или dnf rpm при установке, обновлении и удалении пакетов.

Только root или пользователи с привилегиями sudo могут устанавливать или удалять пакеты RPM.

Вы можете пропустить загрузку и указать URL-адрес RPM-пакета команде rpm :

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

Запрос пакетов RPM

Если пакет установлен, вы увидите что-то вроде этого:

Чтобы получить список всех файлов в установленном пакете RPM:

Если вы хотите узнать, к какому установленному пакету принадлежит конкретный файл, введите:

Проверка пакетов RPM

При проверке пакета команда rpm проверяет, существует ли каждый файл, установленный пакетом, в системе, дайджест файла, право собственности, разрешения и т. Д.

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

Например, следующий результат показывает, что mTime файла был изменен («T»):

Обратитесь к странице руководства RMP о том, что означает каждый символ.

Чтобы проверить все установленные пакеты rpm, выполните следующую команду:

Выводы

rpm — это низкоуровневый инструмент командной строки для установки, запроса, проверки, обновления и удаления пакетов RMP. При установке пакетов RPM следует предпочесть использование yum или dnf поскольку они автоматически разрешают все зависимости за вас.

Если у вас есть какие-либо вопросы или отзывы, не стесняйтесь оставлять комментарии.

Источник

Linux rpm что это

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

Режимы работы rpm

Если вызвать rpm без параметров, то он покажет «краткий» список ключей. Обычно же формат вызова rpm такой:

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

Установку, обновление и удаление пакетов мы рассмотрели ранее, поэтому сейчас остановимся лишь на общих параметрах, получении информации и проверке.

Ключи и параметры, общие для разных режимов

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

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

Получение информации

Какому пакету принадлежит файл

А как там назывался пакет.

Другой пример («к чему там относится afterstep?»):

Где же был этот файл.

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

Информация о неинсталлированном пакете

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

В вышеприведенном примере видно, что данный пакет установить не удастся, как минимум потому, что установленная версия пакета gtk+ слишком старая.

Проверка

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

Сравниваются следующие параметры: 5 Контрольная сумма (подсчитанная по алгоритму MD5) S Размер файла L Куда указывает символьный линк (если проверяемый файл является симлинком) T Время модификации D Устройство (раздел), на котором расположен файл U Владелец G Группа-владелец M Права доступа

Проверку лучше выполнять как » root «, так как некоторые файлы (например, /usr/X11R6/bin/xterm ) могут быть недоступны на чтение другим пользователям и для них всегда будет выдаваться несовпадение по контрольной сумме.

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

Где еще брать информацию про rpm

Источник

Основы RPM

ROSA Desktop — дистрибутив операционной системы GNU/Linux — выпускается и издаётся компанией РОСА, силами различных добровольцев, тестеров, переводчиков.

Содержание

Предисловие

Предполагается, что читатель имеет опыт использования Linux. Ему должны быть известны основные команды, структура каталогов, и ему уже приходилось использовать rpm хотя бы для установки пакетов.

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

В первом приближении, RPM обозначает три понятия:

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

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

Установка программного обеспечения

Основы

Хотя изначально программа rpm была разработана для дистрибутива Red Hat Linux, она также работает и в других дистрибутивах, основанных на rpm: OpenMandriva, Suse, Fedora и т. д.; на всех этих системах программа rpm уже установлена.

Бинарный rpm-пакет, который вы будете собирать для ROSA, может не работать в других дистрибутивах.

Сборка пакетов для ROSA Desktop

Предварительные задачи

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

Замените $ARCH на название архитектуры, для который планируется выполнять сборку. Обычно это i586 или x86_64, но может быть также sparc, alpha или ppc.

Дерево каталогов должно иметь следующую структуру:

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

/rpm/RPMS : содержит каталоги, по одному каталогу на каждую архитектуру, куда кладутся бинарные пакеты после сборки.

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

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

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

/rpm/SOURCES : файлы исходного кода (например, mypackage.tar.bz2 ).

/rpm/SPECS : спек-файлы, которые мы должны построить.

/rpm/SRPMS : собранные src.rpm-пакеты.

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

/rpm/RPMS. Если они отсутствуют, вы получите сообщение об ошибке.

Сборка RPM

Из существующих «исходников» RPM

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

Последнюю версию rpm-файла можно взять из Cooker. Список зеркал Cooker находится на странице зеркала Cooker. Там можно найти:

* ‘media/jpackage для бинарных rpm noarch. (jpackage нет)

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

Журнал сборки может быть достаточно объёмным, его можно сохранить для последующего просмотра.

/rpm/BUILD обычно можно получить доступ к пропатченным «исходникам» (если один или более патчей находились в каталоге

/rpm/SOURCES ), бинарникам, скомпилированным библиотекам, страницам руководств и т. д. Спек-файл описывает исходный код и патч-файлы, способы сборки и установки пакета.

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

. К нему можно получить доступ на cvs.mandriva.com.

Сборка из исходных текстов

Допустим, вы нашли интересную программу на сайте Freshmeat или Sourceforge, и вы хотите, чтобы эта программа стала доступной для всех пользователей ROSA Desktop.

Предварительные проверки

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

Вот мы и добрались до одной из важнейших глав этого документа. Spec-файл содержит всю необходимую информацию для:

Мы рассмотрим основные возможности, используемые в одном из спек-файлов. По мере того, как вы будете собирать всё больше и больше rpm-пакетов, вы поймёте, что существуют некоторые дополнительные параметры, о которых мы не рассказывали. Более подробную информацию можно получить в книге Maximum RPM (см. раздел 7).

Рассмотрим следующий пример спек-файла, взятого из Cooker:

Символ «%» в начале строки может означать:

Раздел заголовка (header)

Кроме того, есть несколько тегов, о которых вы, возможно, захотели бы узнать, но которых нет в примере спек-файла. Есть некоторые теги, которые вы можете встретить. Никто не требует, чтобы вы помнили все теги, если вы только приступили к сборке rpm-пакетов, но после некоторого времени этот список может послужить хорошей отправной точкой!

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

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

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

Эта строка представляет собой описание пакета.

Если файлов с исходным кодом несколько, используйте несколько строк, начинающихся с Source1: …, Source2: … и т. д. соответственно.

Это необязательный тег. Его можно использовать в двух случаях:

Эта строка указывает на домашнюю страницу программы. Её использование не является обязательным, но мы всё же рекомендуем её указывать.

Полная структура групп, которая, кстати говоря, отличается от аналогичных групп Red Hat, представлена на странице Packaging group. Очень важно следовать принятым соглашениям о группах, иначе ваш пакет внесёт неразбериху в дерево пакетов.

Этот тег определяет лицензию, выбранную держателем авторских прав, которая будет применяться к программному обеспечению, находящемуся в пакете. Чаще всего это GPL. На страницах лицензии РОСА и политика лицензирования представлены полные списки разрешённых к использованию лицензий.

в Provides указывается имя библиотеки, которая может использоваться другими программами (предоставляется)

Можно использовать требование к минимальной (или конкретной) версии. Например:

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

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

Ниже следует тег описания:

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

Эти файлы хранятся в poSPECS модуле в CVS Cooker. Когда создаётся новый пакет, основной po-файл автоматически создаётся в этом модуле для будущих переводов.

Раздел подготовки к сборке (prep)

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

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

Есть и другие интересные возможности при использовании макроса %setup :

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

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

При сборке и тестировании вашего пакета, вы должны удостовериться, что целевой хост действительно является i586; особенно, когда компиляция происходит на процессорах более высокого типа, конфигурационный скрипт по умолчанию должен обнаружить ваш процессор, и произвести для него оптимизацию. Цель макроса %configure отменить это поведение.

Для исходников, использующих xmkmf, вы должны заменить следующий make этим:

Для других пакетов, в большинстве случае (но не во всех) будет работать и просто make.

Раздел установки (install)

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

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

Это строка устанавливает программу в симулируемый установочный каталог для autoconf-исходников. Этот макрос будет расширен до » make install » со множеством параметров для установки в симулируемый каталог %, например, и т. д.

В некоторых случаях сценарий configure может быть частично поломан. Возможно, вам понадобится погрузится в Makefile’ы, чтобы найти дополнительные параметры, чтобы установить его правильно. Один из наиболее распространённых: иногда вам нужно использовать make DESTDIR=% install.

Чтобы сохранить место на жёстком диске и время загрузки, ROSA использует lzma для сжатия man и info страниц. Это делается автоматически инструментарием rpm.

Раздел очистки (clean)

Раздел файлов (files)

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

/rpm/tmp/gif2png-buildroot ), чтобы увидеть, какие файлы предполагается положить в пакет (чаще всего кладутся все файлы).

Замечание о структуре каталогов: установленные файлы пакета должны следовать рекомендациям FHS http://www.pathname.com/fhs.

Этот тег задаёт атрибуты, которые будут применяться ко всем файлам, копируемым в систему пользователя. Аргументы означают:

Рекомендуется перечислять в отдельности каждую man или info-страницу.

Как вы можете видеть, для каждого необходимого пути есть макрос нужного типа. Вот наиболее полезные: (полный список доступен в файле /usr/lib/rpm/macros ): % <_prefix>, % <_bindir>, % <_sbindir>, % <_datadir>, % <_libdir>, % <_sysconfdir>, % <_mandir>, % <_infodir>. Для игр используйте % <_gamesbindir>и % <_gamesdatadir>.

Раздел журнала изменений (changelog)

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

Что такое журналы изменений

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

Затем следует одна строка, начинающаяся с «-», в которой описывается изменение в пакете.

По умолчанию в собранный пакет помещаются только записи не старше 1 года. Это поведение может быть изменено настройкой значения %_changelog_truncate

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

Информация для секции changelog автоматически генерируется из истории изменений системы контроля версий. Каждая строка сообщения из истории изменений становится записью в секции changelog, начинающейся с дефиса. Сообщения автоматически группируются по имени и email-адресу автора.

Если вы не хотите, чтобы строка из истории изменений попала в changelog пакета, добавьте в начале строки «SILENT: «. Пустые строки также игнорируются.

Сборка

Процесс может закончиться со следующими результатами:

There are then two possibilities for the last line of your process:

You are in the second case? Congratulations you passed the test, you are not an alien.

Good luck, so long, have a look to rpm building options ( man rpmbuild ) to debug your work, look at other persons’ specfiles, etc..

Оптимизация процесса сборки

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

Сборочный кластер ROSA имеет множество таких предустановленных пакетов для разработки (devel-пакетов). В случае, если один из обязательных пакетов не был перечислен в спек-файле, пакет будет собран на кластере в любом случае. Но отсутствие такой информации не позволит собрать пакет на машинах, на которых отсутствует devel-пакет, делая отладку и обновление более трудной.

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

Чтобы найти эти «missing BuildRequires», выполняя сборку, в системе должны присутствовать только самые основные пакеты для разработки:

Запуская сборку, следите за сообщениями checking for.

Если вы увидите что-то наподобие checking for foo. foo.h not found, это означает, что заголовочный файл в вашей системе не найден. Найдите пакет для разработк, содержащий foo.h, но будьте осторожны: вы можете найти больше одного пакета. Поэтому выберите тот, что подходит в наибольшей степени. К примеру, не следует выбирать пакет, имеющий отношение к компьютерной сети, если вы собираете приложение, предназначенное для работы со звуком.

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

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

Проверка RPM-пакета

Основные проверки

Перво-наперво нужно проверить следующее:

Запуск Rpmlint

Install test

Теперь необходимо проверить установку и обновление пакета на любой машине (желательно отличной от той, на которой проходила сборка), и удостовериться, что:

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

Что-то пошло не так?

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

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

Предустановочные и постустановочные сценарии

Основы

RPM-пакет представляет из себя нечто большее, чем просто архив с файлами, которые извлекаются в определённые каталоги на клиентских системах.

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

Эти сценарии создаются из любых допустимых команд интерпретатора командной строки. Вот четыре из них:

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

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

Работа с обновлениями

Работа с пакетами осложняется тем фактом, что пакет может быть обновлен, а не просто установлен или удален. проблема заключается в том, что при обновлении скрипт %postun новой версии пакета запускается после скрипта %post старой версии, и то, что сделал последний скрипт, может быть потеряно.

Для проверки значение параметра, можно использовать следующую конструкцию:

Файловые триггеры

More macros

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

Созданный файл необходимо указать в секции files:

Макрос %create_ghostfile будет развернут в следующую конструкцию:

Interaction with urpmi and rpmdrake

README.install.urpmi is displayed only for installed packages; README.update.urpmi only for upgraded packages; README.urpmi is displayed in both cases.

Группы пакетов ROSA

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

Лицензии

По вопросам, относящимся к лицензиям ПО, собираемого в пакеты, обращайтесь к Licensing policy.

Alternative: checkinstall

Источник