Alt linux как установить rpm

Обновлено: 07.07.2024

Форматом пакетов в ALT Linux является RPM. Поэтому сборка rpm-пакета здесь может производиться так же как и в любом дистрибутиве Linux, основанном на RPM. Но, как и у большинства дистрибутивов, у ALT Linux есть свои особенности. К основным относятся:

запрещение сборки пакетов суперпользователем; ; .

Соглашения и обозначения

Для исключения неоднозначных толкований необходимо определиться с используемыми далее по тексту терминами и обозначениями. Будем использовать макросы и переменные окружения, определённые в самом ALT RPM:

%_topdir - каталог верхнего уровня, содержащий в себе стандартную иерархию каталогов RPM, в которой производится сборка пакета. По умолчанию значение этого макроса равно $HOME/RPM;
%_sourcedir - макрос, указывающий на каталог с исходными кодами программы, собираемой в пакет. Значение по умолчанию - %_topdir/SOURCES;
%_specdir - каталог, содержащий spec-файл. Значение по умолчанию - %_topdir/SPECS;
%_srcrpmdir - каталог, в котором будет содержаться собранный пакет с исходным кодом (src.rpm).Значение по умолчанию - %_topdir/SRPMS;
%_rpmdir/%_arch - каталог, содержащий подкаталоги с именами различных архитектур (%_arch), для которых производится сборка пакета. Собранный бинарный пакет будет помещён в один из этих подкаталогов. Значение макроса %_rpmdir по умолчанию - %_topdir/RPMS.

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

Кроме того, обозначим переменной GIT_DIR каталог, в котором будет находиться копия git-репозитария MC.

Подготовка к сборке

Для сборки пакета mc необходимо получить исходный код в одном из форматов: либо git-репозитарий, либо тарболл (tar.bz2 или tar.gz). Тарболл также можно самостоятельно изготовить, имея копию репозитария. Для создания тарболла из git-репозитария необходимо выполнить следующие действия:

Перейти в каталог $GIT_DIR.
Установить все необходимые для сборки пакеты. В ALT Linux штатной программой установки пакетов является apt-get.
Выполнить команду

В результате этого в $GIT_DIR появится файл c именем вида mc-<версия>.tar.gz. Если вместо make dist использовать make dist-bzip2, то файл будет иметь имя вида mc-<версия>.tar.bz2. Далее из этого тарболла будет собираться rpm-пакет.

В принципе, в тарболл можно упаковать содержимое git-репозитария (без каталога .git):

tar cjf mc-<версия>.tar.bz2 --exclude '*/.git' mc

В этом случае команды

должны будут выполняться при сборке rpm-пакета.

Сборка с использованием rpmbuild

Для сборки rpm-пакетов надо установить пакеты rpm-build и rpm-utils.

sudo apt-get install rpm-build

Далее надо создать иерархию каталогов %_topdir. В %_sourcedir надо скопировать полученный тарболл, а в %_specdir создать файл mc.spec. В качестве исходного можно взять spec-файл пакета mc, находящегося в apt-репозитарии Sisyphus. В spec-файле надо отредактировать номера версии (Version) и релиза (Release), а также желательно сделать запись в секции %changelog о данной сборке. Для добавления записи в %changelog удобно пользоваться утилитой add_changelog из пакета rpm-utils.

Бинарный пакет собирается командой

rpmbuild -bb mс.spec

запущенной в каталоге %_specdir, а пакет с исходным кодом - командой

rpmbuild -bs mс.spec.

Оба пакета одновременно можно собрать командой

rpmbuild -ba mс.spec.

После сборки бинарный пакет будет находиться в каталоге %_rpmdir/%_arch, а пакет с исходным кодом - в каталоге %_srcrpmdir.

Сборка с использованием hasher

О том, что такое hasher, о его установке и настройке можно прочитать здесь.

Установка программного обеспечения - очень важный момент в работе с операционной системой. Сейчас есть две самые распространенные системы установки программного обеспечения. Это используемая в Debian и всех ее производных, в том числе и в Ubuntu - deb, а также разработанная в RedHat и используемая в Red Hat и всех основанных на ней дистрибутивов - rpm.

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

Основы

С точки зрения пользователя, эти два варианта установки пакетов не имеют очень больших различий. Оба файла и Deb и Rpm - это всего лишь архивы, созданные с помощью утилиты ar. Эти архивы включают в себя файлы программ, исполняемые файлы, библиотеки, или файлы конфигурации. Кроме этого, в каждый пакет входят метаданные системы управления пакетами, именно этим и отличаются rpm и deb. Собственно файлы пакетов отличаются в основном только этим, но еще есть система управления пакетами. А там уже различий в базе данных намного больше.

Давайте рассмотрим каждую систему управления пакетами подробнее, а затем сравним что же в них особенного, и что лучше rpm или deb.

RPM (Red Hat Package Manager)

Как мы уже говорили, RPM - это менеджер пакетов, используемый в операционных системах, основанных на Red Hat, это вся ветка дистрибутивов: Fedora, OpenSUSE, Red Hat, CentOS и т д. Изначально этот пакетный менеджер был разработан в компании Red Hat еще в 1997 году и только для их дистрибутива, но затем он распространился и в другие операционные системы. Вместо обычного сжатия здесь используется сжатие gzip по алгоритму cpio и особый формат файла архива, его мы рассмотрим ниже. Здесь в сравнении rpm или deb, первый кажется лучше, но не все так просто, если в системе нет нужных утилит, то вы не сможете распаковать такой пакет. Кроме cpio могут использоваться и другие алгоритмы сжатия, например, lzma или xz. В последнее время все программное обеспечение подписывается ключами для удостоверения подлинности, вот и RPM поддерживает подпись с помощью GPG и MD5. Технология PatchRPMs или DeltaRPMs позволяет грамотно обновлять RPM пакеты без больших затрат трафика.

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

Для работы с RPM могут использоваться несколько различных пакетных менеджеров, это универсальная утилита rpm, пакетный менеджер zypper в OpenSUSE, dnf в Fedora, urpmi в Mageia, yum - во многих дистрибутивах, основанных на Fedora.

Рассмотрим основные особенности RPM:

Автоматическое разрешение зависимостей в большинстве случаев корректно
Файл архива имеет специальный формат
Не поддерживается реализация зависимостей с выбором завистимости от пакет1 или пакет2.
Не поддерживаются рекомендованные пакеты
Позволяет настроить зависимость от файла, а не пакета
Все данные об установленных пакетах хранятся в базе данных поэтому при надобности можно проверить контрольные суммы
Поддерживаются сценарии как до, так и после установки программ
Поддерживается формат SRPM, который содержит в себе исходники программы все патчи с инструкции по сборке, позволяющие собрать программу из исходников на локальной машине.
Отличная поддержка Multilib пакетов

Deb (Debian Package Manager)

Файлы deb - это архивы, созданные с помощью утилиты ar. Они могут быть сжаты с помощью GZIP, Bzip2, lzma, или XZ. Чаще всего для управления пакетами deb в терминале используется утилита dpkg, Но могут и другие, например, gdebi, apt, aptitude и т д. Deb пакеты используются для установки программного обеспечения во многих операционных системах, основанных на Debian, это ветка Ubuntu со многими основанными на ней дистрибутивами и так далее. Поскольку Ubuntu в последнее время набирает популярность среди новичков, то пакетов для нее становится больше.

Из особенностей системы управления пакетами DEB можно назвать использование приоритетов для классификации пакетов по важности, а также поддержку рекомендованных пакетов. Это пакеты, которые не находятся в зависимостях программы, но желательны для установки вместе с ней. Рекомендованные утилиты устанавливаются автоматически в таком инструменте, как apt. Чтобы сравнить rpm vs deb рассмотрим особенности deb:

Файл пакета - обычный архив
Поддержка приоритетов для пакетов различной важности
Поддержка рекомендованных пакетов
Не поддерживаются файловые зависимости
Не поддерживается технология Delta для экономии трафика

Аналоги команд

Давайте рассмотрим аналоги команд для выполнения одних и тех же действий в этих системах управления пакетами с помощью утилит rpm и dpkg:

В современных системах на базе Linux огромное число общих ресурсов, которыми пользуются сразу несколько программ: разделяемых библиотек, содержащих стандартные функции, исполняемых файлов, сценариев и стандартных утилит и т. д. Удаление или изменение версии одного из составляющих систему компонентов может повлечь неработоспособность других, связанных с ним компонентов, или даже вывести из строя всю систему. В контексте системного администрирования проблемы такого рода называют нарушением целостности системы. Задача администратора — обеспечить наличие в системе согласованных версий всех необходимых программных компонентов (обеспечение целостности системы).

Для установки, удаления и обновления программ и поддержания целостности системы в Linux в первую очередь стали использоваться менеджеры пакетов (такие, как rpm в дистрибутивах RedHat или dpkg в Debian GNU/Linux ). С точки зрения менеджера пакетов программное обеспечение представляет собой набор компонентов — программных пакетов. Такие компоненты содержат в себе набор исполняемых программ и вспомогательных файлов, необходимых для корректной работы программного обеспечения. Менеджеры пакетов облегчают установку программ: они позволяют проверить наличие необходимых для работы устанавливаемой программы компонент подходящей версии непосредственно в момент установки, а также производят необходимые процедуры для регистрации программы во всех операционных средах пользователя: cразу после установки программа может быть доступна пользователю из командной строки и — если это педусмотрено — появляется в меню всех графических оболочек.

Важно

Благодаря менеджерам пакетов, пользователю Linux обычно не требуется непосредственно обращаться к установочным процедурам отдельных программ или непосредственно работать с каталогами, в которых установлены исполняемые файлы и компоненты программ (обычно это /usr/bin , /usr/share/ имя_пакета ) — всю работу делает менеджер пакетов. Поэтому установку, обновление и удаление программ в Linux обычно называют управлением пакетами.

Часто компоненты, используемые различными программами, выделяют в отдельные пакеты и помечают, что для работы ПО, предоставляемого пакетом A, необходимо установить пакет B. В таком случае говорят, что пакет A зависит от пакета B или что между пакетами A и B существует зависимость.

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

Задача контроля целостности и непротиворечивости установленного в системе ПО ещё сложнее. Представим, что некие программы A и B требуют наличия в системе компоненты C версии 1.0. Обновление версии пакета A, требующее обновления компоненты C до новой, использующей новый интерфейс доступа, версии (скажем, до версии 2.0), влечёт за собой обязательное обновление и программы B.

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

Наши партнеры

Глава 3. Управление пакетами
Пред.	Часть II. Настройка системы	След.

Глава 3. Управление пакетами

В нашем дистрибутиве программы (состоящие, как правило, из нескольких файлов) распространяются объединенными в пакеты формата RPM (RedHat Packet Manager).

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

Часто бывает удобнее, однако, применять программу rpmdrake, разработанную MandrakeSoft, kpackage из KDE, gnorpm из GNOME или систему apt, подробно описанную на стр. .

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

Далее приводятся возможные параметры. вставить насчет rpm4, db3, ^C, rm -f /var/lib/rpm/__* ---- mike, 02.22.2002, 18:58 ----

Установка пакета. Вы можете установить программу, используя опцию -i (опции -v и -h выставлены здесь для того, чтобы включить визуальное отображение процесса установки). Например, для того, чтобы установить klyx, наберите:

(настоящее имя зависит от версии программы на доступном носителе).

то есть, например, для пакета klyx :

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

-qi используется для получения некоторой информации о ранее установленном пакете;
-qip используется для еще не установленных пакетов. В этом случае вы должны указать полный путь и имя пакета (например, /mnt/cdrom/Mandrake/RPMS/klyx-0.10.9-ipl6mdk.i586.rpm );
-ql используется для того, чтобы просмотреть список файлов пакета. Добавьте p, если пакет еще не был установлен;
-qa выдает список всех установленных пакетов (не нужно указывать имя пакета).

Для получения дополнительной информации наберите man rpm.

Обеспечение и поддержание целостности системы с помощью APT

Введение

Для целей поддержания целостности и обеспечения возможности распространения программ в двоичном виде в первую очередь стали использоваться менеджеры пакетов (такие, как RPM в дистрибутивах RedHat Linux или dpkg в Debian GNU/Linux). Менеджеры пакетов давали возможность унифицировать и автоматизировать сборку двоичных пакетов и облегчали их установку, позволяя проверять наличие необходимых для работы устанавливаемой программы компонент подходящей версии непосредственно в момент установки. Однако менеджеры пакетов оказались неспособны предотвратить все возможные коллизии при установке или удалении программ, а тем более эффективно устранить нарушения целостности системы. Особенно сильно этот недостаток сказывается при обновлении систем из централизованного репозитария пакетов, в котором последние могут непрерывно обновляться, дробится на более мелкие и т.д. Этот недостаток и стимулировал создание систем управления программными пакетами и поддержания целостности системы.

Усовершенствованная система управления программными пакетами APT (Advanced Packaging Tool) первоначально была разработана для управления установкой и удалением программ в дистрибутиве Debian GNU/Linux. При разработке ставилась задача заменить используемую в Debian систему выбора программных пакетов dselect на новую, обладающую большими возможностями и простым пользовательским интерфейсом, а также позволяющую производить установку, обновление и повседневные "хозяйственные" работы с установленными на машине программами без необходимости изучения тонкостей используемой в дистрибутиве менеджера программных пакетов.

Эти привлекательные возможности были долгое время доступны только пользователям Debian GNU/Linux, поскольку в APT поддерживалась только один менеджер пакетов, а именно применяемый в Debian GNU/Linux менеджер пакетов dpkg , несовместимый с используемой в ALTLinux RPM. Эта несовместимость заключается прежде всего в различии используемых форматов данных (хотя сущесвуют программы-конверторы), хотя имеютсяа и другие различия, обсуждение которых выходит за рамки изложения.

APT, однако, изначально проектировался, как не зависящий от конкретного метода работы с установленными в системе пакетами, и эта особенность позволила разработчикам из бразильской компании Conectiva реализовать в нем поддержку менеджера пакетов RPM. Таким образом, пользователи основанных на RPM дистрибутивов ( ALTLinux входит в их число) получили возможность использовать этот мощный инструмент.

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

Задача контроля целостности и непротиворечивости установленного в системе ПО еще сложнее. Представим, что некие программы A и B требуют наличия в системе компоненты C версии 1.0. Обновление версии пакета A, требующее обновления компоненты C до новой, использующей новый интерфейс доступа, версии (скажем, до версии 2.0), влечет за собой обязательное обновление и программы B.

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

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

Использование APT

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

apt-get позволяет устанавливать в систему пакеты, требующих для своей работы других, пока еще не установленных. В этом случае он определяет, какие из отсутствующих пакетов необходимо установить, и доустанавливает их, пользуясь всеми доступными репозитариями. Для того, чтобы apt-get мог использовать тот или иной репозитарий, информацию о нем необходимо поместить в файл /etc/apt/sources.list и выполнить команду

Эту команду необходимо также выполнять каждый раз, когда вы собираетесь работать с репозитарием после длительного перерыва, так как при поиске пакетов APT должен руководствоваться базой данных, отражающей актуальное состояние репозитария. Такая база данных создается заново каждый раз, когда в репозитарии происходит изменение: добавление, удаление или переименование пакета. Для ускорения работы apt-get хранит локальную копию базы данных, которая через некоторое время может уже не соответствовать реальному состоянию репозитария.

В качестве источника пакетов можно использовать и компакт-диски дистрибутива, поскольку на каждом диске присутствует вся необходимая для APT информация о содержащихся на нем пакетах. Для этого необходимо использовать утилиту apt-cdrom с единственным параметром add :

Повторите этот процесс для всех CD в вашем наборе.

После этого в /etc/apt/sources.list появится запись о подключенном диске:

Если подключение к Internet отсутствует, то следует закомментировать те строчки в /etc/apt/sources.list , в которых говорится о ресурсах, доступных по Сети. Непосредственно после установки дистрибутива ALTLinux в /etc/apt/sources.list указаны несколько таких источников:

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

Установка пакета с помощью APT, выполняется командой

Команда apt-get install имя_пакета используется и для обновления уже установленного пакета или группы пакетов. В этом случае apt-get дополнительно проверяет, не обновилась ли версия пакета в репозитарии по сравнению с установленным в системе. Если вы не знаете точное название пакета, для его поиска можно воспользоваться утилитой apt-cache, описанной ниже.

Пример 3.1. Установка пакета clanbomber командой apt-get install clanbomber приведет к следующему диалогу с APT:

Внимание

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

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

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

Для удаления пакета используется команда apt-get remove имя_пакета. Для того, чтобы не нарушать целостность системы, будут удалены и все пакеты, зависящие от удаляемого: если отсутствует необходимая для работы приложения библиотека, то само приложение становится бесполезным). В случае удаления пакета, который относится к базовым компонентам системы, apt-get потребует дополнительного подтверждения производимой операции с целью предотвратить возможную случайную ошибку.

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

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

Для обновления всех установленных пакетов используется команда apt-get upgrade. Она позволяет обновить те и только те установленные пакеты, для которых в репозитариях, перечисленных в /etc/apt/sources.list , имеются новые версии; при этом из системы не будут удалены никакие другие пакеты. Этот способ полезен при работе со стабильными пакетами приложений, относительно которых известно, что они при смене версии изменяются несущественно.

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

При работе с Sisyphus для обновления системы рекомендуется использовать команду apt-get dist-upgrade.

Поиск в репозитарии

Для поиска нужного пакета можно воспользоваться утилитой apt-cache, которая позволяет искать не только по имени пакета, но и по его описанию.

Команда apt-cache search подстрока позволяет найти все пакеты, в именах или описании которых присутствует указанная подстрока. Например:

Для того, чтобы подробнее узнать о пакете, можно воспользоваться командой apt-cache show, которая покажет информацию о пакете из репозитария и в том числе:

Настройка APT

Настройка описаний репозитариев задается в файле /etc/apt/sources.list в следующем виде:

Например, при установке ALTLinux в /etc/apt/sources.list записываются следующие настройки:

Более подробное описание команд программы apt-get можно найти в справочной системе дистрибутива на страницах apt-get(8) и apt.conf(5) .

Создание собственного репозитария

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

архитектура, под которую собраны пакет (совпадает с таковой в имени бинарных RPM-пакетов)

название подсистемы. Этот уровень в дереве может отсутствовать (то есть, каталоги RPMS и base могут идти сразу следом за архитектурой)

каталог, в котором размещены бинарные пакеты

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

ссылка на каталог RPMS . При этом sisyphus заменяется на собственное название репозитария, например, local

служебный каталог, в котором размещается база данных APT

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

Тогда строка запуска genbasedir будет выглядеть так:

Репозитарий MyDistro.security , хранящий пакеты с исправлениями ошибок в системе безопасности, имеет смысл подписывать PGP-ключом, чтобы при установке пакета можно было проверить аутентичность репозитария и хранящихся в нем пакетов. Для этого необходимо создать соответствующий PGP-ключ, используя программу GnuPG (gpg) и запомнить его отпечаток (fingerprint) на клиентских машинах в файле /etc/apt/vendors.list в формате:

Примером может служить ключ службы безопасности ALT Linux Team , которым подписаны пакеты репозитария Sisyphus и обновления безопасности для различных дистрибутивов ALTLinux :

Для того, чтобы APT проверял аутентичность подписи, необходимо указать, что соответствующий репозитарий подписан PGP-ключом в /etc/apt/sources.list :

Необходимо также сгенерировать информацию для APT в репозитарии с указанием опции --sign команды genbasedir. Дополнительно, можно указать идентификатор ключа, если он отличается от ключа по умолчанию, используя опцию --uid=идентификатор . Значением этой опции является идентификатор ключа в том виде, как он передается программе GnuPG в опции --default-key :

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

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