менеджер пакетов rosa linux

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

Содержание

Программа управления приложениями

В системе имеется несколько программ, помогающих в управлении программным обеспечением. Наиболее важными являются программы установки, удаления приложений ( rpmdrake / drakrpm).

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

Программа управления программным обеспечением называется rpmdrake / drakrpm.
С её помощью также можно управлять сетевыми репозиториями (источниками программ) и репозиториями на сменных носителях. rpmdrake / drakrpm можно запустить несколькими способами:

Фильтры пакетов при разных способах запуска

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

В РОСА версии 2010.2 ) и более поздних rpmdrake / drakrpm запускается с фильтром «пакеты с графическим интерфейсом».

Команда rpmdrake-remove запускает rpmdrake / drakrpm с фильтром «установлен». Использование этого фильтра позволяет получить пользователю список всех установленных в системе пакетов, что является наиболее удобным способом представления списка для операций удаления пакетов из системы.

«Просмотр доступного программного обеспечения» (в «Управлении программами») запускает rpmdrake / drakrpm без прав администратора. В этом случае пользователь может просматривать установленные в системе пакеты, а также просматривать пакеты, доступные для установки, но ни удалять ни устанавливать пакеты в этом режиме нельзя.

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

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

Если программа обновления была запущена впервые с момента установки РОСА Linux на ваш компьютер, она спросит разрешения на подключение к серверам РОСА, чтобы получить список зеркал, с которых можно загружать обновления. После получения вашего согласия на подключение, программа попросит выбрать наиболее географически близкое к вам месторасположение зеркала. После того, как зеркало выбрано, программа получит список доступных обновлений. По умолчанию программа получает список пакетов, исправляющих проблемы с безопасностью и критически важные ошибки (баг-фиксы).

Дополнительные приложения

После процедуры установки РОСА Linux на компьютер пользователь будет иметь доступ только к программному обеспечению, находящемуся на CD или DVD (в зависимости от того, с какого носителя была произведена установка). Конечно, количество доступных программ в таком случае невелико. Для того, чтобы получить доступ к дополнительным приложениям, необходимо настроить систему на использование общедоступных репозиториев, содержащих пакеты для РОСА Linux.

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

Опытным пользователям. Консольные инструменты управления пакетами

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

Полное описание этих приложений выходит за рамки этой страницы. Более подробную информацию можно получить на этой странице.

Коротко о программах

urpmi

urpme

urpmq и urpmf

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

urpmi.addmedia и urpmi.removemedia

Эти инструменты предназначены для добавления и удаления репозиториев. Обратитесь к страницам руководства (man-страницам) для получения информации об использовании необходимых параметров. Существует несколько веб-сайтов, которые помогут сгенерировать команды для добавления репозиториев программ с помощью urpmi.addmedia. Два наиболее популярных веб-ресурса: официальный поиск зеркал Mandriva и поддерживаемые сообществом веб-сайты EasyUrpmi, urpmi.mandriva.ru.

Опытным пользователям. Репозитории backports и testing

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

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

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

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

Сторонние репозитории

Можно поискать сторонние репозитории для РОСА/Mandriva Linux. Они могут содержать программы, версии которых новее чем те, что содержатся в официальных репозиториях. Кроме того, можно найти пакеты, которых вообще нет в официальных репозиториях.

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

РОСА/Mandriva не может предоставить какую-либо поддержку для пакетов, предоставляемых третьими сторонами. При возникновении проблем, связанных с использованием таких пакетов, просьба обращаться за поддержкой к стороннему поставщику этих пакетов.

Очень многие пользователи жалуются: «Это приложение не работает!» На этот счёт можно дать несколько рекомендаций. Старайтесь использовать приложения из официальных репозиториев. Помните, что приоритетным является использование именно официальных репозиториев. Кроме того, использование новейшей версии пакета (и, возможно, содержащей ошибки) не так важно, как использование более старой, но лучше оттестированной версии. Если использование программы более новой версии так критично, её можно найти в backports.

Пересборка с помощью source RPM более позднего релиза РОСА Linux

Если необходим какой-либо пакет или его версия, отсутствующий в официальном или стороннем репозиториях для данного релиза РОСА Linux, но доступный для последующих релизов (включая Cooker), можно попробовать перекомпилировать SRPM из более позднего релиза. Source RPM можно найти на любом официальном зеркале РОСА в подкаталоге релиза /SRPMS, где имеется необходимый вам пакет. Для создания source RPM, следуйте инструкциям из Основы RPM: Вам нужно будет выполнить шаги из раздела «Предварительные задачи», а затем, следовать инструкциям раздела «Из существующих «исходников» RPM».

Установка программ с использование исходных кодов

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

Источник

ROSAForum

Forum about ROSA Linux Distros

Пакетный менеджер

Пакетный менеджер

Сообщение alexferman » 04 июн 2016, 10:21

Здравствуйте. Очень хотелось бы узнать, есть ли у разработчиков Росы планы модернизировать пакетный менеджер, чтобы он не был таким неповоротливым? Или, может, вы планируете перейти на какой-нибудь другой ПМ?

Дело в том, что я попробовал в Virtualbox ваш дистрибутив и он мне очень понравился, но такой пакетный менеджер (urpmi, если я не ошибаюсь) это просто боль после pacman

Может, хотя бы есть какие-то твики, которыми можно заставить urpmi шевелиться быстрее?

Re: Пакетный менеджер

Сообщение VictorR2007 » 04 июн 2016, 10:51

Re: Пакетный менеджер

Сообщение alexferman » 04 июн 2016, 11:22

Re: Пакетный менеджер

Сообщение VictorR2007 » 04 июн 2016, 11:38

Re: Пакетный менеджер

Сообщение vvpnet » 04 июн 2016, 13:55

Re: Пакетный менеджер

Сообщение alexferman » 04 июн 2016, 15:13

Re: Пакетный менеджер

Сообщение alexferman » 04 июн 2016, 16:14

Запустил обновление в виртуалке, обновляются почти 1000 пакетов. В сравнении с другими дистрибутивами в такой же виртуалке, rpmdrake отрабатывает намного медленнее. Очень долгое обновление, капец.

Re: Пакетный менеджер

Сообщение trs » 04 июн 2016, 16:23

Re: Пакетный менеджер

Сообщение alexferman » 04 июн 2016, 16:41

Re: Пакетный менеджер

Сообщение VictorR2007 » 04 июн 2016, 16:43

alexferman писал(а): Запустил обновление в виртуалке, обновляются почти 1000 пакетов. В сравнении с другими дистрибутивами в такой же виртуалке, rpmdrake отрабатывает намного медленнее. Очень долгое обновление, капец.

Источник

ROSAForum

Forum about ROSA Linux Distros

Пакетный менеджер

Пакетный менеджер

Сообщение alexferman » 04 июн 2016, 10:21

Здравствуйте. Очень хотелось бы узнать, есть ли у разработчиков Росы планы модернизировать пакетный менеджер, чтобы он не был таким неповоротливым? Или, может, вы планируете перейти на какой-нибудь другой ПМ?

Дело в том, что я попробовал в Virtualbox ваш дистрибутив и он мне очень понравился, но такой пакетный менеджер (urpmi, если я не ошибаюсь) это просто боль после pacman

Может, хотя бы есть какие-то твики, которыми можно заставить urpmi шевелиться быстрее?

Re: Пакетный менеджер

Сообщение VictorR2007 » 04 июн 2016, 10:51

Re: Пакетный менеджер

Сообщение alexferman » 04 июн 2016, 11:22

Re: Пакетный менеджер

Сообщение VictorR2007 » 04 июн 2016, 11:38

Re: Пакетный менеджер

Сообщение vvpnet » 04 июн 2016, 13:55

Re: Пакетный менеджер

Сообщение alexferman » 04 июн 2016, 15:13

Re: Пакетный менеджер

Сообщение alexferman » 04 июн 2016, 16:14

Запустил обновление в виртуалке, обновляются почти 1000 пакетов. В сравнении с другими дистрибутивами в такой же виртуалке, rpmdrake отрабатывает намного медленнее. Очень долгое обновление, капец.

Re: Пакетный менеджер

Сообщение trs » 04 июн 2016, 16:23

Re: Пакетный менеджер

Сообщение alexferman » 04 июн 2016, 16:41

Re: Пакетный менеджер

Сообщение VictorR2007 » 04 июн 2016, 16:43

alexferman писал(а): Запустил обновление в виртуалке, обновляются почти 1000 пакетов. В сравнении с другими дистрибутивами в такой же виртуалке, rpmdrake отрабатывает намного медленнее. Очень долгое обновление, капец.

Источник

Основы 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 старой версии, и то, что сделал последний скрипт, может быть потеряно.

Таблица A-1. Значение параметра, передаваемого pre и post скриптам

Параметр \ Скрипт %pre %post %preun %postun
первоначальная установка 1 1 N/C N/C
обновление 2 2 1 1
удаление N/C N/C 0 0

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

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

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

Источник

Понравилась статья? Поделиться с друзьями:

Не пропустите наши новые статьи:

  • менеджер пакетов linux debian
  • менеджер пакетов kali linux
  • менеджер операционных систем для windows 10
  • менеджер окон windows 10
  • менеджер окон mac os

  • Операционные системы и программное обеспечение
    0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest
    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии