Алексей Федорчук. Книга о FOSS, Unix, Linux, BSD, Solaris и свободных программах для них
Настройка Fedora тесно связана с установкой дополнительных пакетов. Далеко не все из них есть в основном официальном репозитории — fedora.repo, который только и задействуется при установке с оригинальных носителей проекта. Так что для начала надо обеспечить доступ к дополнительным репозиториям. Читать дальше »
Чтобы настраивать параметры доступа к репозиториям, их необходимо сначала подключить. Как это сделать посредством PackageKit мы уже рассматривали. Но там речь шла о репозиториях, уже задействованных на стадии установки — оставалось только решить, нужно ли их использовать. А вот задача подключения совсем “левых” (пусть даже и очень “правых”, но не входящих в официальный список) хранилищ пакетов средствами PackageKit не решается. Читать дальше »
А пока обратимся к плагинам. Они устанавливаются точно так же, как и любые другие пакеты. Например, команда
# yum install yum-plugin-list-data
установит весьма полезный одноименный плагин, дополняющий субкоманду list множеством дополнительных фильтров (он заслуживает отдельного разговора).
Соответствующие каждому из установленных плагинов конфигурационные файлы располагаются в каталоге /etc/yum/pluginconf.d и имеют легко узнаваемые имена. Например, вывод команды
$ ls yum/pluginconf.d/ blacklist.conf list-data.conf refresh-packagekit.conf fastestmirror.conf presto.conf whiteout.conf
позволит без труда догадаться, к какому из плагинов относится любой конфиг (кроме файлов blacklist.conf и whiteout.conf).
Некоторые конфиги предельно просты. Например, в list-data.conf есть одна-единственная строка, разрешающее его подключение:
enabled=1
В конфиге плагина presto (того самого, который при обновлении обеспечивает скачивание дельты вместо цельного пакета) простора больше, хотя тоже не очень много. Во-первых, можно запретить локальное кэширование этих самых дельт, раскомментировав параметр
# keepdeltas = false
А во-вторых, можно определить, что же считать дельтой. Например, параметр
minimum_percentage = 95
определяет, что если изменённая часть пакета составляет 95% или менее от цельного, то будет скачиваться она, если же больше — загрузится пакет целиком.
Что касается файлов blacklist.conf и whiteout.conf, то по умолчанию они пусты, содержа только запрещающую строку:
enabled=0
Нетрудно догадаться, что их можно заполнить “черными” и “белыми” списками зеркал.
Плагин yum-plugin-list-data добавляет множество дополнительных субкоманд, позволяющих получать разнообразную информацию о пакетах и их разработчиках. Поскольку рассортировать их по какому-либо признаку, хотя бы с точки зрения полезности, у меня не получилось, пробегусь по ним в алфавитном порядке: Читать дальше »
Как было сказано на странице, посвященной базовым средствам yum, система эта, помимо главного пакета, включает комплекс сопутствующих утилит и плагинов. Из них на стадии инсталляции по умолчанию устанавливается пакет yum-utils, а в RFRemix 11 — ешё и несколько очень важных плагинов. Читать дальше »
Как было сказано на одной из предыдущих страниц, посвященной базовым средствам yum, система эта, помимо главного пакета, включает комплекс сопутствующих утилит и плагинов. Из них на стадии инсталляции по умолчанию устанавливается пакет yum-utils, а в RFRemix 11 — ешё и несколько очень важных плагинов. Читать дальше »
Практическое использование yum начнём с субкоманды list — можно было бы и с любой другой, но это показалось мне логичней: ведь прежде чем заняться каким-либо манипулированием пакетами, не худо изнать, какие пакеты вообще имеются, какие из них установлены, какие — доступны. Читать дальше »
Система yum включает в себя собственно одноимённую утилиту, набор дополнительных утилит (yum-utils) и многочисленные плагины, образующие самостоятельные пакеты и расширяющие функциональность главной программы. Читать дальше »
Аббревиатура yum интерпретируется как Yellow dog Updater, Modified, то есть Обновитель Yellow dog Модифицированный. Что заставляет предполагать его связь с одноимённым дистрибутивом — портом (см. о клонах, портах etc.) Red Hat на архитектуру Power. Читать дальше »
Yum — система управления rpm-пакетами и их репозиториями, предлагающая автоматическую установку, обновление и удаление пакетов и пакетных групп с автоматическим контролем зависимостей. По механизму действия и функциональности она сходна с системой APT, разработанной для Debian. Однако, в отличие от последней, за пределами rpm-based дистрибутивов, насколько мне известно, не используется. Читать дальше »
Ознакомившись в общих чертах с устройством rpm-пакетов, посмотрим, что же с ними можно сделать. И начнём с одноимённой утилиты, предназначенной для работы с единичными пакетами — для их поиска, получения информации, установки, обновления и удаления с отслеживанием (но не разрешением) зависимостей. В давние времена она была благословением и проклятием начинающих пользователей дистрибутива Red Hat, его клонов и дериватов.
Благословением — потому что освобождала от необходимости самостоятельной компиляции: практически все разработчики из числа не брезговавших распространением своих пакетов в бинарном виде, собирали их в rpm-формате, а службы вроде позволяли легко отыскать их на просторах Сети. Помню, в те годы имела хождение такая жизненная максима:
с помощью rpm и Инета любые дистрибутивы можно сделать близнецами-братьями за одну ночь
Проклятием — потому что, отслеживая зависимости пакетов при установке и удалении, утилита rpm отнюдь не занималась их разрешением, а только сообщала об обнаруженной крамоле, причём в достаточно неудобопонимаемой форме.
Те времена канули в Лету: наступил век пакетных репозиториев и средств для работы с ними, таких, как apt-rpm, urpmi и, наконец, yum — главный герой следующего цикла заметок. Каковые и берут на себя заботу по рутинному манипулированию пакетами. Однако утилита rpm до сих пор остаётся самым простым средством для операций с единичными пакетами, особенно не входящими в официальные репозитории. А в некоторых случаях — например, при подключении репозиториев сторонних — она может оказаться практически незаменимой.
Так что уделим толику времени знакомству с её базовыми, наиболее востребованными в повседневной жизни, функциями. Это просто краткий конспект для практического применения. Причём ориентированный на тех, кто ранее дела с rpm-based системами не имел. Тех, кто будет из зала кричать — давай подробности, авансом отсылаю к тёте Мане, она за всё расскажет.
Вообще-то, утилита rpm, подобно dpkg в Deb-based дистрибутивах, — лишь одна из представительниц целого семейства, разрабатываемого, вместе с одноимённым форматом, в рамках . Из числа дополнительных утилит стоит упомянуть rpm-build — средство для создания собственных пакетов, и rpm2html — утилиту для извлечения метаинформации из пакетов и представления её в человеческом виде. Надеюсь, что со временем дело дойдёт и до них. Но в настоящей заметке речь пойдёт только о собственно rpm.
В сущности, в обыденной жизни rpm служит преимущественно трём целям:
наличие пакета в системе проверяется так:
$ rpm -qa pkgname
где -q (или --query) — основная опция запроса, а -a (или --all) предписывает запрос ко всем наличным пакетам. Если пакет установлен в системе, ответом на запрос будет
$ rpm -qa opera opera-10.00-4440.gcc4.shared.qt3.x86_64
если нет — возвращение приглашения командной строки.
Отсутствующий пакет устанавливаем так:
# rpm -ihv path2/pkgname.X.Y.rpm
где -i (или --install) — основная опция установки.
Обновление уже установленного пакета при наличии более новой версии производится посредством команды
# rpm -F path2/pkgname.X.Y.rpm
где -F (или --freshen) предписывает освежить существующий пакет.
Суммарная форма установки –
# rpm -U path2/pkgname.X.Y.rpm
При этом существующий пакет будет обновлён, а отсутствующий — установлен.
Ко всем основным опциям установки и обновления можно добавить дополнительные: -v (или --verbose), выводящую сведения о ходе процесса, и -h (или --hash), обеспечивающую удобство представления вывода.
Опции установки или обновления требуют указания полного имени файла пакета и пути к нему.
Удаление единичного пакета ничуть не сложнее:
# rpm -e pkgname
Здесь достаточно базового имени пакета.
В случае нарушения зависимостей при установке, обновлении или удалении выводится сообщение об ошибке, в суть которого мы вникать не будем.
Вот и всё, что на начальном этапе нам потребуется знать о команде rpm. Заинтересованным в деталях дорога, как обычно, к тёте Мане:
$ man rpm
Где и будет рассказано о бессчётных опциях этой утилиты.
Пакет rpm включает в себя два компонента. С одной стороны, это набор скомпилированных файлов, таких, как исполняемые бинарники и библиотеки, сопровождаемых необходимыми конфигами, документацией и т.д.), готовый к инкорпорацию в файловую иерархию системы.
С другой стороны, пакет содержит метаинформацию — составленное по определённым правилам описание. Оно включает имя пакета, номер версии и сборки, сведения о разработчике и его мастер-сайте, список файлов, их положение в файловой иерархии, список зависимостей. При необходимости тут могут присутствовать установочные и настроечные сценарии. Всё это вместе позволяет контролировать целостность пакета, отслеживать зависимости, обеспечивать выполнение собственно процедуры инсталляции, и так далее.
Компоненты rpm-пакета запаковывается в архив cpio — одно из древнейших средств архивирования в UNIX (информацию об этой утилите можно найти здесь), подвергнутый компрессии. Ранее, вплоть до Fedora версии 11 включительно, это делалось посредством утилиты gzip (о ней см. здесь). Начиная с 12-й версии Fedora rpm-пакты сжимаются по алгоритму LZMA, обеспечивающему много большую степень компрессии — правда, ценой времени, на неё затрачиваемого (кое-что на эту тему можно найти здесь). Что для пользователя, впрочем, неудобств не доставит — потому что распаковка lzma-файлов, как это ни парадоксально, осуществляется практически с той же скоростью, что и gzip. А вот скачивание их, разумеется, происходит много быстрее, что не может не радовать обладателей “толстых” и дешёвых каналов: при этих условиях установка пакетов по Сети происходит быстрее, нежели с локальных носителей.
Вернёмся, однако, к тому, что у rpm-пакета “внутре”. Для чего сначала распакуем пакет любым стандартным средством (rpm2cpio, например, или с помощью утилиты rpm2tgz) и посмотрим, что получилось:
$ ls rpm-4.7.1-6/ bin/ etc/ usr/ var/
То есть мы видим те компоненты пакета, которые будут инкорпорировано с файловую иерархию целевой системы.
Знакомство со вторым компонентом проще всего сделать с помощью Midnight Commander. По клавише F3 (по прежнему для примера рассматривается пакет rpm) он выдаст всю синтетическую метаинформацию в таком виде
Name : rpm Relocations: (not relocatable)
Version : 4.7.1 Vendor: Fedora Project
Release : 6.fc12 Build Date: Пнд 21 Сен 2009 17:30:35
Install Date: (not installed) Build Host: x86-3.fedora.phx.redhat.
com
Group : System Environment/Base Source RPM: rpm-4.7.1-6.fc12.src.rpm
Size : 2027173 License: GPLv2+
Signature : RSA/8, Втр 29 Сен 2009 19:37:43, Key ID 9d1cc34857bbccba
Packager : Fedora Project
URL : http://www.rpm.org/
Summary : The RPM package management system
Description :
RPM Package Manager (RPM) - это мощная, управляемая из командной строки
система установки пакетов, способная устанавливать, удалять, проверять
содержимое пакетов и обновлять пакеты программ. Каждый программный пакет
содержит архив файлов одновременно с информацией о версии пакета, его описанием
и т.д.
posttrans scriptlet (using /bin/sh):
# XXX this is klunky and ugly, rpm itself should handle this
dbstat=/usr/lib/rpm/rpmdb_stat
if [ -x "$dbstat" ]; then
if "$dbstat" -e -h /var/lib/rpm 2>&1 | grep -q "doesn't match environment ve
rsion | Invalid argument"; then
rm -f /var/lib/rpm/__db.*
fi
fi
exit 0
и так далее.
Всё это хозяйство можно просмотреть и по частям — нажав Enter на файле
rpm-4.7.1-6.fc12.x86_64.rpm
мы увидим список входящих в него “метаинформационных” файлов:
/.. │-ВВЕРХ-│Дек 16 12:04 /INFO │ 0│Сен 21 00:00│ CONTENTS.cpio │ 0│Сен 21 00:00 HEADER │ 1185│Сен 21 00:00 *INSTALL │ 39│Сен 21 00:00 *UPGRADE │ 39│Сен 21 00:00
О содержимом файлов легко догадаться. Так, CONTENTS.cpio — полный список всех файлов и путей к ним:
-rwxr-xr-x 1 root root 20808 Sep 21 17:30 ./bin/rpm drwxr-xr-x 2 root root 0 Sep 21 17:30 ./etc/rpm ...
и так далее. Файл HEADER содержит то самое описание, которое мы только что видели через F3, *INSTALL и *UPGRADE — исполняемые скрипты соответствующего назначения. А в каталоге /INFO лежит множество мелких файликов, из которых в итоге собирается синтетическая метаинформация. Из них остановлюсь только на REQUIRENAME — это пресловутый перечень зависимостей, который для пакета rpm выглядит примерно так:
/bin/bash /bin/sh /bin/sh config(rpm) = 4.7.1-6.fc12 coreutils curl db4-utils = 4.7.25 libacl.so.1()(64bit) libbz2.so.1()(64bit) ...
И так далее, единым списком, без разделения на зависимости “жесткие” и “мягкие”.
В репозиториях Fedora (и остальных rpm-based дистрибутивов) можно обнаружить разные виды пакетов интересующего нас формата (об устройстве репозиториев мы также поговорим отдельно). Читать дальше »
Как мы знаем из исторической части, изобретение формата пакетов rpm и соответствующей утилиты для управления ими оказало очень большое влияние на Linux-дистрибуцию вообще. Так что пора познакомиться с этими материями поближе. И начнём с рассмотрения формата. Читать дальше »
Фронт-энд kpackagekit по своим функциям, как нетрудно догадаться, практически идентичен описанному на предыдущей странице gnome-packagekit, несколько отличаясь лишь интерфейсом. Читать дальше »
Первая графическая ипостась PackageKit — gnome-packagekit, запускается в виде отдельного субпакета gpk-application из главного стартового меню, в зависимости от используемой среды, через пункты Приложения -> Установка и удаление программ (GNOME) или Администрирование -> Установка и удаление программ (Xfce). Причём сделать это можно от лица обычного пользователя — пароль администратора будет запрашиваться по ходу дела, при необходимости выполнения действий, требующих соответствующих полномочий. Читать дальше »
Пакетные менеджеры дистрибутивов, чьи системы управления пакетов поддерживаются PackageKit, имеют обычно собственный развитый инструментарий для работы в ними в командной строке. Не исключение и Fedora, как мы увидим, когда дело у нас дойдёт до триариев, то есть до yum’а. Поэтому консольная утилита pkcon представляет интерес в основном своей теоретической универсальностью, поскольку предполагается одинаковой в любых дистрибутивах, поддерживающих PackageKit. Так что уделим ей несколько строк. Читать дальше »
Как уже было сказано, в Fedora система PackageKit появилась относительно недавно, в 9-й версии, сменив ранее бывшие штатными сладкую парочку pirut (собственно управление пакетами) и pup (тотальное обновление системы). И ныне, в текущей весии (12-й) успешно справляется с обеими задачами. Читать дальше »
Среди средств установки пакетов первым надо назвать их компиляцию из исходных текстов, как наиболее универсальное и лежащее в первооснове всего — ведь любые бинарники в самом изощренном формате, управляемые самыми хитрыми менеджерами пакетов, некогда были собраны из исходников посредством трех волшебных заклинаний: Читать дальше »