FOSSBook от alv’а

Yum — система управления rpm-пакетами и их репозиториями, предлагающая автоматическую установку, обновление и удаление пакетов и пакетных групп с автоматическим контролем зависимостей. По механизму действия и функциональности она сходна с системой APT, разработанной для Debian. Однако, в отличие от последней, за пределами rpm-based дистрибутивов, насколько мне известно, не используется. Читать дальше »

Ознакомившись в общих чертах с устройством rpm-пакетов, посмотрим, что же с ними можно сделать. И начнём с одноимённой утилиты, предназначенной для работы с единичными пакетами — для их поиска, получения информации, установки, обновления и удаления с отслеживанием (но не разрешением) зависимостей. В давние времена она была благословением и проклятием начинающих пользователей дистрибутива Red Hat, его клонов и дериватов. Читать дальше »

Пакет 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-дистрибуцию вообще. Так что пора познакомиться с этими материями поближе. И начнём с рассмотрения формата. Читать дальше »

Из сказанного можно сделать вывод, что PackageKit в любой из своих графических ипостасей — простое и удобное в обращении средство управления пакетами, функционально сходное с Synaptic’ом для apt. С сравнении с последним он долгое время производил впечатление более медлительного. Однако, начиная с Fedora 12, его задумчивость исчезла напрочь — это относится и к обновлению метаинформации о репозиториях, и собственно к установке пакетов. Читать дальше »

Фронт-энд kpackagekit по своим функциям, как нетрудно догадаться, практически идентичен описанному на предыдущей странице gnome-packagekit, несколько отличаясь лишь интерфейсом. Читать дальше »

Первая графическая ипостась PackageKit — gnome-packagekit, запускается в виде отдельного субпакета gpk-application из главного стартового меню, в зависимости от используемой среды, через пункты Приложения -> Установка и удаление программ (GNOME) или Администрирование -> Установка и удаление программ (Xfce). Причём сделать это можно от лица обычного пользователя — пароль администратора будет запрашиваться по ходу дела, при необходимости выполнения действий, требующих соответствующих полномочий. Читать дальше »

Как уже было сказано, в Fedora система PackageKit появилась относительно недавно, в 9-й версии, сменив ранее бывшие штатными сладкую парочку pirut (собственно управление пакетами) и pup (тотальное обновление системы). И ныне, в текущей весии (12-й) успешно справляется с обеими задачами. Читать дальше »

Описанные на предыдущих страницах способы создания программного RAID прямыми командами соответствующих утилит отличаются гибкостью, но требуют самой малости — наличия уже установленной системы. И потому не позволяют непосредственно разместить на массиве корень файловой иерархии. Правда, создание массива можно выполнить и перед установкой системы — например, с LiveCD. Однако не факт, что он будет опознан инсталляционной программой произвольного дистрибутива. Читать дальше »

Как один из главных недостатков Fedora я уже отмечал архаичность программы установки. А самый скользкий момент её — это разметка дисков. Во-первых, она недостаточно гибка, во-вторых — нередко допускает отсебятину. Например, упорно присваивает некоторым разделам статус первичного или, напротив, логического в расширенном, вне зависимости от отметки соответствующей опции или отсутствия таковой, просто по собственному усмотрению. Читать дальше »

Как было сказано ранее, по умолчанию инсталлятор Fedora предлагает для всех разделов файловую систему ext4. В списке доступных значатся также ext2, ext3 и xfs. А вот наиболее прогрессивной из современных файловых систем, btrfs, мы там не увидим, хотя идущее с Fedora 12 ядро 2.6.31 её поддерживает, хотя и в качестве экспериментальной опции, но зато в самой современной инкарнации — в версии 0.19. Читать дальше »

Ранее мы рассмотрели стандартные методы установки Fedora — в графическом режиме, посредством инсталлятора ayaconda. Однако в этом дистрибутиве предусмотрен и текстовый режим установки. Читать дальше »

Как уже говорилось при общем описании дистрибутива, “живые” диски Fedora также имеют функцию установки на винчестер. И в некоторых случаях это может быть предпочтительным — время тупого ожидания развёртывания системы можно занять чем-нибудь полезным, например, чтением документации. Читать дальше »

Итак, заполучив любой из подходящих для установки носителей, вставляем его в привод и, проверив в BOIS Setup опции, загружаемся с него. После чего имеем удовольствие наблюдать следующую картину: Читать дальше »

Как я уже говорил на соответствующей странице, инсталляционная программа Fedora в наши дни выглядит весьма архаичной. Что, однако, не помешает нам её установить. И даже различными способами: стандартным, с поддержкой файловой системы btrfs, в текстовом режиме. Все их мы и рассмотрим последовательно. Читать дальше »

Остаётся оценить, для каких категорий пользователей подходит дистрибутив Fedora. Для этого кратко пробежимся по его достоинствам, о которых немало говорилось выше, и недостаткам, про которые не было ещё сказано ни слова. Читать дальше »

Отдельно надо сказать о проекте Russian Fedora. Он был начат ровно год назад, 22 ноября 2008 года, и ставил себе целью, с одной стороны, лучшую адаптацию дистрибутива к российским условиям, а с другой — улучшение связи между российскими разработчиками Fedora и “головной организацией” проекта. Читать дальше »

Релизы дистрибутива для обеих интересующих нас архитектур распространяются в виде образов установочных дисков (или их наборов) и как LiveCD с возможностью установки. Читать дальше »

Дистрибутив Fedora формально ведёт счёт своей жизни с 5 ноября 2003 года, когда было официально объявлено о выходе его первой версии. Однако до этого он вёл латентное существование в лоне десктопных вариантов дистрибутива Red Hat, поэтому на самом деле история его восходит к самой заре дистростроения. Читать дальше »