архив

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

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

2009-07-08

Как я говорил в предыдущей заметке , одной из главных целей моего приобщения к 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 Hat 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, прошедший все проверки. О чём — в следующем номере нашей программы.