Linux и все, все, все... Статьи и колонки в LinuxFormat, 2006-2013
Шрифт:
Однако нельзя исключить ситуации, что в ходе проверки зависимостей будут выявлены ошибки – как правило, они связаны с конфликтом версий пакетов, от которых зависит устанавливаемый. И единственное, что тут можно сделать – открыть вывод More details, тупо просмотреть его и закрыть панель ошибок. Выбранный пакет при этом, разумеется, установлен не будет.
Удаление пакетов происходит аналогично – только в обратном порядке:
Подчёркиваю необходимость очень внимательного изучения списка удаляемых зависимостей: они могут оказаться весьма неожиданными. Так, удаление пакета, установленного не индивидуально, а в составе какой-либо группы или коллекции (особенно при инсталляции), может нечувствительно вызвать снос половины системы.
PackageKit в 12-й версии Fedora получит (за счёт отдельных плагинов) такие дополнительные возможности, как автоматическая установка пакетов по щелчку на имени файла в браузере или из командной строки – в ответ на сообщение command not found.
Все действия по установке и удалению пакетов (а также тотальному обновлению системы, о чём будет говориться позднее) через PackageKit фиксируются в специальном лог-файле – /var/log/yum.log; как явствует из названия, он не специфичен для этой системы, а отражает действия через менеджер пакетов yum. Однако gnome-packagekit предоставляет удобную форму визуализации его содержимого, вызываемую через пункты меню System -> Software log, где показываются: дата действия и его характер (установка, обновление или удаление), имя совершившего его пользователя и приложения (субпакета в составе gnome-packagekit):
Рис. 4. Журнал установки, обновления и удаления пакетов
Однако по хорошему, прежде чем заниматься установкой или удалением пакетов, не худо выполнить некоторые подготовительные действия.
Первое из них – проверить доступные репозитории, те самые, которые подключались на стадии установки, что делается через меню System -> Software sources. Скорее всего, все нужные источники пакетов из числа официальных для Fedora вообще и Russian Fedora в частности уже включены, но лишний раз убедиться в этом не мешает.
Затем имеет смысл обновить систему – через пункт меню System -> Refresh package lists, который сначала приведёт список доступных пакетов в актуальное (и соответствующее подключённым репозиториям) состояние, а затем предложит список пакетов, могущих быть обновлёнными, с которым остаётся только согласиться.
И теперь обновление будет выполнено, если не произойдёт ошибки —. хотя нельзя исключить и последнего варианта. В этом случае придётся обратиться к командной строке и yum’у.
Пунктами меню Software sources и Refresh package lists вызывают самостоятельные субпакеты, входящие в gnome-packagekit – gpk-repo и gpk-update-viewer, соответственно. Но они могут быть запущены автономно, через главное стартовое меню среды – Система -> Администрирование -> Источники программ/Обновление программ.
Из сказанного можно сделать вывод, что PackageKit в своей графической ипостаси – простое и удобное в обращении средство управления пакетами, функционально сходное с Synaptic’ом для deb-пакетов. В сравнении с последним он производит впечатление более медлительного. Однако это связано не с ним самим, а с rpm-форматом и базами данных для yum, требующими скачивания существенно большего объёма метаинформации. Второй недостаток PackageKit – трудность определения причин возникновения ошибок как при установке конкретного пакета, так и тотального обновления системы. Это я отнёс бы к некоторой недоработанности системы PackageKit в целом – ведь по сравнению с Synaptic’ом она ещё очень молода.
Однако и в нынешнем своём виде PackageKit пригоден для повседневного использования в сфере управления пакетами, если не выходить за пределы штатных ситуаций – при их возникновении yum нам в руки.
openSUSE LiveCD: нетривиальная установка
LinuxFormat, #162 (октябрь 2012)
Большинство современных дистрибутивов Linux распространяется в двух основных вариантах: в виде образов оптических дисков, служащих исключительно для установки системы, и в виде образов LiveCD/DVD, предназначенных как для знакомства с ней, так и и для последующей инсталляции. Не исключение тут и openSUSE, официальный набор образов которой включает:
О последних и пойдёт речь в настоящей статье.
Вступление
Среди записных линуксоидов, вне зависимости от используемого дистрибутива, существует несколько пренебрежительное отношение к установке системы с «живых» дисков: обычно считается, что этот метод предназначен для совсем начинающих пользователей, устанавливающих свой первый в жизни Linux. Пользователям же с опытом должно применять альтернативные установочные носители.
Это мнение имеет под собой основания: в большинстве случаев при установке с LiveCD возможности пользователя вмешаться в этот процесс минимальны или напрочь отсутствуют. Результатом же такой установки является точная копия образа «живого» диска со всеми его умолчальными настройками и заранее предопределённым набором приложений. А поскольку в отношении последних предпочтения составителей LiveCD наверняка не на 100% совпадают с предпочтениями пользователя «со стажем», в дальнейшем ему придётся затратить немало времени на индивидуализацию своей системы.
Однако инсталляция openSUSE с LiveCD оказывается исключением из общего правила. И предоставляет не меньше возможностей по индивидуализации системы, нежели установка с полного DVD или «сетевого» диска. А в отношении настроек – даже больше. Как это оказывается возможным – и будет предметом настоящей статьи.
Как уже было сказано, официально в рамках проекта распространяется два варианта LiveCD – с KDE и GNOME в качестве рабочих сред, каждый в сборках для 32-битной и 64-битной архитектур. В силу личных предпочтений автора дальнейшее изложение проводится на примере KDE-LiveCD – но пользователи GNOME вполне могут применить те же приёмы при установке своего любимого десктопа.