Fedora — не горе: обновление системы

Алексей Федорчук

Как я говорил в предыдущей заметке, одной из главных целей моего приобщения к Fedora, кроме повышения общеобразовательного уровня, было опробование новой модификации файловой системы btrfs (версии 0.19), каковая обещала скачок в быстродействии файловых операций. Для чего надлежало обновить установленную систему до «сыромятной» её версии, содержащей, помимо всего прочего, ядро 2.6.31-rc1, эту модификацию поддерживающее.

С этой целью перво-наперво я обратился к штатному средству управления пакетами нашего дистрибутива, именуемому PackageKit. Это — кросс-дистрибутивная надстройка над различными системами пакетного менеджмента, такими, как yum или apt (говорят, он умеет работать даже с tar.gz пакетами из Archlinux).

PackageKit включает backend’ы для работы с различными менеджерами пакетов (в Fedora это yum backend) и графические frontend’ы, предназначенные для работы в средах KDE (kpackagekit) или GNOME (gnome-packagekit). Поскольку я устанавливал Xfce, использующий GNOME’вские библиотеки, именно второй и оказался в моём распоряжении.

В среде Xfce PackageKit запускается из главного стартового меню: Администрирование -> Установка и удаление программ. После чего мы видим примерно следующую картину:

Очевидно, что первое, что тут нужно сделать — проверить, как обстоит дело с репозиториями. Для чего отправляемся в меню System, где выбираем пункт Software sources. После чего мы видим четыре теоретически доступных репозитория, из которых по умолчанию включены два:

1. Fedora 11.90 — x86_64
2. Fedora 11.90 — x86_64 Updates

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

1. Fedora 11.90 — x86_64 Test Updates
2. Fedora Rawhide

Интересно, что при этом основные репозитории релиза отключились сами собой:

Если есть потребность в доступе к репозиториям исходников (пакетам srpm — у меня такой потребности пока не возникло), следует «поставить птицу» на Show debug and development software sources и из расширенного списка выбрать нужное, например, Fedora Rawhide — Source.Теперь через меню System -> Refresh package lists надо обновить списки доступных пакетов, и если в оных появятся обновления (а при переходе на разрабатываемую версию они появятся неизбежно), возникнет следующая панель:

Тут, казалось бы, всё просто: нажать кнопку Установить обновления — и дело в шляпе, по аналогии с классово близкими менеджерами пакетов типа Synaptic или Xnetpkg можно ожидать, что остальное произойдёт само собой. Но не тут-то было — вместо сообщения о благополучном завершении появляется такая вот панель:

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

Однако печальный итог таков, что никакого обновления при этом не происходит — даже для тех пакетов, у которых с зависимостями всё в порядке. То есть работает принцип — всё или никак. И разрешить данную коллизию в рамках PackageKit невозможно. По крайней мере, я не нашёл, как это можно сделать.

Надо отметить, что механизм обновления можно запустить и отдельно — через меню  Администрирование -> Источники программ (для подключения репозиторие) и Администрирование -> Обновление программ (для собственно обновления). Но, поскольку при этом используется всё тот же PackageKit, результат будет аналогичным, то есть нулевым.

Но тут вовремя вспомнился далёкий 2001 год, когда я сочинял документацию к первой коробочной версии ASPLinux’а, в которой использовался пакетный менеджер yum, употребимый нынче в Fedora, Red Hat и его клонах. В скобках замечу, что долгое время yum в собственно Red Har etc. был в загоне, а развивался именно силами разработчиков ASPLinux’а, но это отдельная история.

Освежив свои воспоминания с помощью руководстваи, разумеется, тёти Мани (man yum), я, получив права root’а посредством su, бестрепетно ввёл в командной строке терминала команду

# yum update

Каковая должна выполнить полное обновление как списка доступных пакетов, так и собственно системы.

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

# yum update --skip-broken

Теперь, наконец, система обновилась до «сыромятной» версии, и можно было заняться доустановкой пакетов.

С этой целью я опять-таки сначала воспользовался PackageKit’ом — и с переменным успехом. Некоторые пакеты устанавливались нормально, со всеми зависимостями. Иные же опять-таки выдавали ошибки в разрешении зависимостей. И потому пришлось снова обратиться к командной строке и yum‘у, что выглядит примерно так:

# yum install имя_рек

Однако оказалось, что пакеты, которые отказывались устанавливаться через PackageKit, в yum‘е с полпинка также не вставали, выдавая для некоторых их зависимостей такое сообщение:

Package имя_рек.rpm is not signed

Правда, это решилось достаточно просто — достаточно было установить проблемный пакет индивидуально:

# yum install имя_рек1

После того, как все проблемные зависимости были установлены таким образом, и собственно главный пакет инсталлировался благополучно.

В отношении же некоторых пакетов пришлось прибегнуть к классическому rpm, например, только таким способом мне удалось установить браузер Opera (поскольку бета-версия FireFox в первоначальном виде оказалась почти неработоспособной — хотя нынешняя, релизная, функционирует вполне справно):

prm -ihv path2/opera-9.64.gcc4-shared-qt3.x86_64.rpm

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

• PackageKit показался мне простым и удобным в обращении, но несколько недоработанным; в частности, в нём очень трудно определить причины ошибки при установке конкретного пакета;
• yum, напротив, произвёл на меня очень хорошее впечатление — не уступая по возможностям семейству apt, он несколько проще синтаксически;
• ну а rpm — он и в Африке rpm, и пользоваться им следует только в том случае, если нет другого выхода.

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