CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
09.12.2016

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Приложения :: Управление пакетами

Debian и его клоны: управление пакетами

Основы пакетного менеджмента

Как говорилось в исторических очерках (вообще о Linux и о Debian в частности), формат пакетов (deb) этого дистрибутива, как и средства пакетного менеджмента - в числе выдающихся достижений его разработчиков, унаследованное всеми Debian-клонами.

Пакет Debian - архивный файл (собранный утилитой ar), содержащий два обычных архива *.tar.gz, один из которых включает скомпилированные исполняемые бинарники (и необходимые им для работы компоненты - библиотеки, конфиги, документацию и так далее), второй же - так называемые управляющие файлы: контрольные суммы, описания зависимостей, пред- и постинсталляционные сценарии.

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

Понятие зависимостей в Debian и его производных отличается от принятого в большинстве других дистрибутивов (и вообще ОС Unix-семейства). Обычно различаются только

  • обязательные (или "жесткие") зависимости, без удовлетворения которых установка и работа программы невозможна (например, зависимость от системных библиотек), и
  • зависимости необязательные ("мягкие"), без разрешения которых программа сохраняет работоспособность, но удовлетворение их добавляет ей функциональности (например, зависимость links или mc от сервиса консольной мыши gpm).

В Debian зависимости имеют несколько градаций: обязательные (depends), настоятельно рекомендуемые (recommends), рекомендуемые умеренно настойчиво (suggests), конфликтующие (conflicts). Первая градация - это обычные "жесткие" зависимости. С последними тоже понятно - это, так сказать, анти-зависимости. Ну а настоятельно рекомендуемые и рекомендуемые просто - это две разновидности "мягких" зависимостей. То есть первая категория как бы более нужная, нежели вторая. Впрочем, таково субъективное мнение майнтайнера данного пакета - вполне возможно, что у пользователя будут иные потребности. И это мы учтем при выборе средства управления пакетами.

Кроме того, спецификой Debian является еще и существование так называех пред-зависимостей (pre-depends) - при их нарушении установка пакета даже не может начаться. Впрочем, с точки зрения пользователя они немногим отличаются от обычных зависимостей типа depends.

Кроме зависимостей, в системах пакетного менеджмента Debian важно также понятие приоритета пакета. отражающее степень необходимости его для функционирования системы, например: обязательный (required), без которого функционирование системы невозможно, основной (base) и важный (important), также оказывающиеся практически необходимыми, стандартный (standard) - то есть имеющийся практически в любой полнофункциональной Linux-системе, дополнительный (optional) - тут уж степень важности каждый должен решать для себя.

Как это принято в мире Open Source, все бинарные пакеты Debian (а также, конечно, Ubuntu и других клонов) сопровождаются исходными текстами, доступными из репозиториев дистрибутива. И здесь Debian проявляет свою специфику: каждый пакет в исходниках обычно включает три файла - packagename.orig.tar.gz, packagename.dsc и packagename.diff.gz.

Первый - самый обычный тарбалл исходных текстов авторского пакета, что подчеркивается словом orig в его имени: имя и система нумерации версий также совпадают с таковыми авторского пакета. Файл packagename.dsc содержит в себе всю метаинформацию, необходимую для правильного построения из него бинарного deb-пакета (как - будет рассказано в следующих разделах). А packagename.diff.gz - это те изменения исходного кода, которые вносятся для адаптации пакета непосредственно к данному дистрибутиву. Если таких изменений не потребовалось (или если пакет писался именно для Debian), он может и отсутствовать.

Средства управления пакетами Debian: обзор

В отношении средств управления пакетами в Debian и его клонах имеется богатый выбор:

  • команда dpkg, предназначенная для установки, конфигурирования и удаления единичных пакетов, но не имеющая собственных средств разрешения зависимостей между ними;
  • dselect - front-end (оболочка) для dpkg, работающая в текстовом режиме; обеспечивает не только установку/удаление программ, но и групповой выбор пакетов по целевому назначению, а также разрешение зависимостей между ними;
  • механизм apt - универсальный набор инструментов для управления deb-пакетами, включая разрешение зависимостей между ними и даже построение из исходников отдельных пакетов и тотальную пересборку установленной системы с заданными параметрами компиляции;
  • aptitude - оболочка для apt, как по интерфейсу, так и функционально схожая с dselect;
  • sinaptic - также оболочка для утилит семейства apt.

Все эти средства унаследованы от прародителя - Debian'а его клонами. Которые, однако, могут включать в себя и собственный инструментарий пакетного менеджмента. Так, в Kubuntu имеется собственный менеджер пакетов - Adept, предназначенный для работы в графической среде KDE.

В этой статье речь пойдет о семействе программ dpkg и инструментарии apt. Надстраивающие их front-end'ы лично мне представляются неудобными (хотя многие имеют другое мнение), и я ими никогда не пользуюсь. Кроме того, отличительная черта dselect и, насколько я знаю, aptitude - то, что они по умолчанию устанавливают все зависимости пакетов, как обязательные (depends), так и рекомендуемые обеих степеней (recommend и suggests), что представляется далеко не всегда оправданным.

Команда dpkg разрешением зависимостей не занимается, лишь сообщая в соответствующих случаях о их нарушениях. Инструменты же из набора apt, ограничваясь установкой необходимых зависимостей, выводят список настоятельно и умеренно рекомендуемых пакетов, и пользователь может сам решить, устанавливать ему их или нет.

Что же касается Adept - это очень интересная программа (также, насколько я понимаю, front-end над apt, но ее еще нельзя считать достаточно отлаженной. Будем надеяться на совершенствование ее в грядущих версиях Kubuntu.

Семейство команд dpkg

Начнем мы с семейства команд dpkg - в ряде случаев это простейший способ установить единичный пакет и незаменимое средство его конфигурирования. С помощью этой команды можно также легко получить подробную информацию о пакете. И вообще, возможности ее очень широки. Но все они тут рассматриваться не будут - с ними легко ознакомиться на странице man (1) dpkg. Мы же ограничимся необходимым минимумом.

Итак, если нам необходимо установить единичный пакет, поступаем так:

$ sudo dpkg -i path2/packagename.deb

и дело в шляпе - через считанные мгновения пакет packagename.deb будет установлен: это обеспечивает опция -i вслед за командой dpkg (ну и команда sudo здесь необходима - ведь установка пакета требует полномочий администратора). Разумеется, при соблюдении следующих условий:

  1. физическом наличии его в пределах досягаемости с локальной машины (на подключенной файловой системе, смонтированном комапакт-диске или ином носителе);
  2. знании точного пути (path2) к нужному файлу пакета (имя его, кстати, также указывается полностью, в отличие от того, что мы увидим, когда речь дойдет до apt);
  3. отсутствии неудовлетворенных зависимостей.

Из первого условия следует, что dpkg удобно использовать при доустановке компонентов с инсталляционного CD/DVD (или установке заблаговременно скачанных пакетов). Второе условие самоочевидно. Ну а третье также выполнимо без особого труда: в случае нарушения зависимостей dpkg выдаст сообщение об ошибке с полным перечнем того, что нужно установить для ее устранения, причем в списке будут перечислены только обязательные зависимости. И достаточно все необходимые пакеты поместить в командную строку:

$ sudo dpkg -i path2/packagename1.deb ... path2/packagename#.deb

для того, чтобы они были установлены единой операцией (если, конечно, все эти пакеты имеются в наличии).

Другое часто требующееся применение команды dpkg - удаление ненужных пакетов. Это делается двояко: команда

$ sudo dpkg -r packagename

удалит пакето, но сохранит настроечные его файлы, а команда

$ sudo dpkg -P packagename

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

Обратим внимание - в аргументах обеих команд фигурирует уже не полное имя пакета, а только его значимая часть. Это распространяется на все случаи использования dpkg (и других команд ее семейства), когда речь идет об уже установленных пакетах.

Потому что вообще-то dpkg - это действительно нечто вроде семейства команд, включающее, кроме себя самой, еще несколько: dpkg-deb, dpkg-query и так далее. Один из представителей этого семейства, который так и называется - dpkg-reconfigure, служит цели переконфигурирования уже установленных пакетов. Делается это так:

$ sudo dpkg-reconfigure packagename

После этого вызывается диалоговая программа конфигурации - debconf, и ответы на серию более или менее тривиальных вопросов позволяют добиться желаемого результата (как это выглядит на практике, мы увидим в следующей главе, на примере пакета console-cyrillic).

Еще одна сфера деятельности команд семейства dpkg - получение информации о пакетах. Для уже установленных пакетов это проще всего сделать с помощью команды dpkg-query, требующей указания какого-либо из операторов действия и имени пакета в качестве аргумента. Операторы действия команды dpkg-query можно вывести так (поскольку получение информации о пакетах никак не влияет на систему в целом, необходимости в правах суперпользователя тут не возникает, и потому команда sudo не нужна):

$ dpkg-query --help

Они следующие:

  • -s или --status - вывод детального статуса пакета, включающий:
    • имя пакета, собственно статус (установлен ли он) и приоритет;
    • секция репозитория, к которой пакета относится (например, editors - для текстовых редакторов, kde - для аудиоплейера amarok, и так далее);
    • размер пакета в установленном виде;
    • имя майнтайнера, архитектура, для которой пакет собран, и номер версии;
    • описание зависимостей и конфликтов;
    • краткое (в один абзац) описание пакета.
  • -p или --print-avail - практически то же самое, но в форме, приспособленной для печати;
  • -l или --list - тоже своего рода описание статуса, включающее сведения о том, установлен ли пакет, нуждается ли он в одновлении, нет ли ошибок в его настройке, и так далее;
  • -W или --show - просто вывод номера версии в форме:
    	$ dpkg-query -W nano
    	nano    1.3.8-2
    	
  • -L или --listfiles - полный список файлов, относящихся к данному пакету, в форме:
    	/.
    	/etc
    	/etc/nanorc
    	/usr
    	/usr/share
    	/usr/share/doc
    	/usr/share/doc/nano
    	...
    	
    и так далее (пример для текстового редактора nano);
  • -S или --search - поиск пакета, к которому относится некий файл, указанный в качестве аргумента; может выполнить и обратную задачу - поиск всех файлов, принадлежащих данному пакету, вывод в этом случае оказывается аналогичным dpkg-query -L.

Повторю, что все сказанное о информации по пакетам, относится к пакетам уже установленным. Для получения же сведений о неустановленных пакетах удобнее использовать соответствующие инструменты из комплекта apt, к рассмотрению которого мы и переходим.

Настройка доступа к репозиториям пакетов

Программный комплекс apt - мощнейшее средство управления пакетами, охватывающее все аспекты этого захватывающего занятия. Однако первое, чего он требует - это настройки доступа репозиториям пакетов. Ниже этот вопрос рассмотрен на примере дистрибутивов Ubuntu и Kubuntu - пакетные репозитории едины для всего семейства. Однако практически все сказанное применимо и к исходному Debian, и к любому из его клонов - они сохраняют совместимость, и deb-пакеты из, скажем, Xandros (включая такие спецфичные, как драйверы устройств), могут использоваться в Kubuntu, и наоборот.

После обычной пользовательской установки Ubuntu и Kubuntu мы имеем доступ только к одному такому репозиторию - установочному CD или DVD. Причем первый нам практически не нужен - почти все его содержимое и так устанавливается по умолчанию в ходе первичной инсталляции. На DVD, конечно, есть большое количество дополнительных пакетов - но и ими не обойтись, кое-какие компоненты (те же аудио- и видеокодеки) можно получить только из репозиториев сетевых.

Источники пакетов, получаемых через apt, описываются в специальном конфигурационном файле - /etc/apt/sources.list. После пользовательской установки по умолчанию он содержит строку вида

deb cdrom:[Kubuntu 5.10 _Breezy Badger_ - Release i386 (20051012)]/ breezy main restricted

описывающую репозиторий на установочном компакт-диске, плюс еще несколько закомментированных строк, распадающихся на отдельные секции.

Формат каждой строки таков:

  • тип пакета - deb для бинарников и deb-src для исходников;
  • URL архива - в наших условиях это будет http://ru.archive.ubuntu.com/ubuntu;
  • имя собственное дистрибутива - для текущей версии breezy (собственно дистрибутив), breezy-updates, breezy-backports, breezy-security (дополнительные компоненты;
  • тип репозитория - main и restricted (основная часть дистрибутива, поддерживаемая командой обновления безопасности), universe и multiverse (дополнительная часть, лишенная соответствующей поддержки).

Вдаваться в различия между типами репозиториев не буду - достаточно запомнить, что нам они понадобятся все, включая и те, что являются как бы не совсем официальными (universe и multiverse). Так что достаточно просто снять комментарии со всех строк, начинающихся с deb и deb-src - как станет ясным в дальнейшем, некоторые пакеты, возможно, придется строить из исходников:

## Uncomment the following two lines to fetch updated software from the network
deb http://ru.archive.ubuntu.com/ubuntu breezy main restricted
deb-src http://ru.archive.ubuntu.com/ubuntu breezy main restricted

и так далее. Обращаю внимание - в этих (и аналогичных) строках фигурируют только репозиторий Ubuntu и имя дистрибутива, ни слова о Kubuntu мы тут не найдем. То есть, если мы снесем KDE с нашей инсталляции Kubuntu и поставим из репозитория GNOME - то получим чистый Ubuntu, и наоборот. Это я и имел ввиду, когда говорил о легкой трансформации одного дистрибутива этого семейства в другой.

А можно поступить еще интересней: отказаться и от KDE, и от GNOME, установив, например, XFce - и таким образом преобразить свой дистрибутив в Xubuntu (мысли о таком проекте в народе циркулируют). Или - заменить XFce на любой из полусотни имеющихся в репозитории менеджеров окон (например, Window Maker), после чего стать счастливым обладателем собственного уникального WMubuntu. В общем, перспективы индивидуализации системы открываются безграничные.

Кстати, не менее легко сменить релизную версию на тестируемую: для этого достаточно во всех строках файла /etc/apt/sources.list заменить breezy на dapper. А при необходимости воспользоваться репозиториями родительского Debian или какого-либо из его клонов - дописать соответствующие строки (руководствуясь документацией к требуемому дистрибутиву).

В случае, если коннект с репозиторием http://ru.archive.ubuntu.com/ubuntu оказывается неудовлетворительным (а подчас так и бывает), никто не запрещает добавить какие-либо иные зеркала официального репозитория. По моим наблюдениям, самыми быстрыми оказываются норвежское, бельгийское и нидерландское. Так что каждую строку с описанием отдельных репозиториев можно продублировать, заменив в URL ru на no, be или nl, соотвественно.

Сделанного достаточно, чтобы доустанавливать пакеты из дистрибутива, не включенные в комплект установочного компакт-диска, а также получать все штатные обновления. Однако время от времени появляются и обновления не вполне штатные. Так, текущая версия Kubuntu включает KDE версии 3.4.3, которая при штатном обновлении остается неизменной (меняются только номера сборки пакетов). Однако для Kubuntu доступна и сборка KDE версии 3.5.X, которая лежит в собственном репозитории, который подключается такой строкой:

deb http://kubuntu.org/packages/kde35 breezy main

После этого необходимо скачать gpg-ключ (нечто вроде гарантии идентичности):

$ wget http://people.ubuntu.com/~jriddell/kubuntu-packages-jriddell-key.gpg

и выполнить собственно процедуру идентификации:

$ sudo apt-key add kubuntu-packages-jriddell-key.gpg

Аналогично следует поступать и с другими "не вполне штатными" обновлениями, например, аудиоплейера amaroK. Следить за такими вещами проще всего по сайту проекта http://www.kubuntu.org. А по приводимым там ссылкам обычно содержится исчерпывающая информация о том, как подключать такие дополнительные репозитории.

И, наконец, для получения пакетов типа w32codecs и ему подобных, существуют уж совсем неофициальные репозитории, например, такой:

deb ftp://cipherfunk.org/pub/packages/ubuntu

Только, ради Бога, не подумайте, что это какой-то Linux'овый warez, ни в коем случае. Просто там помещаются пакеты, использующие алгоритмы, которые в некоторых осталых странах (типа США) защищаются всякого рода патентами. Семейство же дистрибутивов Ubuntu создавалось в расчете на международное распространение, и потому его разработчики вынуждены учитывать любые лицензионные ограничения всех стран мира.

Инструментарий apt

Набор apt (Advanced Packaging Tools), как следует из его названия - это программный комплекс, охватывающий все стороны управления пакетами, вплоть даже до их построения из исходных текстов. Он включает в себя почти десяток команд, из которых нынче нас заинтересуют только три - apt-cache, средство работы с кэшем пакетов, apt-get - инструмент для их получения и установки, и apt-build - программа сборки пакета из исходных текстов формата deb-src. Они тесно переплетаются друг с другом, поэтому рассматривать их придется попеременно - примерно в том порядке, как они используются в реальной работе.

Но сначала - несколько слов об общем синтаксисе команд семейства apt. Каждая из этих команд, кроме более или менее многочисленных опций, имеет еще так называемые операторы, предписывающие, что же именно она должна делать, тогда как смысл опций - в уточнении выполняемого действия. Аргументами же команд служат имена пакетов (их значимой части); некоторые операторы аргументов не требуют вообще. Звучит, может быть, не очень понятно, но при рассмотрении примеров все станет ясным.

Назначение команды apt-cache - в получении информации о пакетах, причем не только установленных на локальной машине, но и находящихся в сетевых репозиториях, причем даже при запуске на локальной машине, не обязательно подключенной к сети (хотя в целом без сети использование ее ограничено). Откуда apt-cache берет эту информацию? Из локальной базы данных, создаваемой во время инсталляции системы, и в дальнейшем обновляемой с помощью apt-get, чему служит специальный опертор update.

Итак, первое, что надлежит сделать после установки системы - обновить кэш пакетов (особенно если со дня выхода установочного компакт-диска прошло какое-то время):

$ sudo apt-get update

Программа устанавливает соединение со всеми репозиториями, перечисленными в файле /etc/apt/sources.list, и приведет локальный кэш пакетов в соответствие с их актуальным состоянием. Что, разумеется, уже предполагает сетевое подключение - иначе базу данных можно было бы обновлять только с установочного компакт-диска или иного локального носителя. Что, впрочем, тоже не возбраняется - при отсутствии сети именно так проще всего обновить систему с дистрибутива более свежей версии на CD или DVD. Только предварительно нужно, во-первых, позаботиться, чтобы CD был правильно описан в файле /etc/fstab, например, вот так:

/dev/hdc /media/cdrom0 udf,iso9660 user,noauto 0 0

Что, впрочем, обычно корректно выполняется на стадии первичной установки. А во-вторых, выполнить такую команду:

$ apt-cdrom add

Ее посредством правильное описание репозитория на новом диске будет добавлено в файл /etc/apt/sources.list lines.

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

$ sudo apt-get upgrade

сравнит версии установленных пакетов с обновленным их кэшем, выявит все компоненты, нуждающиеся в обновлении, скачает соответствующие их версии из сети (или вытащит их из свежего компакта) и заменит ими пакеты устаревшие. В случае, если новые версии повлекут за собой и новые зависимости, по сравнению с имевшимися ранее, - они также будут скачаны и установлены. Но перед этим будет выведен полный список пакетов, нуждающихся в обновлении, число файлов, который предстоит скачать из сети, и их суммарный объем, значение, на которое возрастет занятое дисковое пространство в результате всех этих действий, и последует запрос на подтверждение операции обновления.

Пакеты, скачиваемые при исполнении apt-get upgrade (это относится и к описываемым ниже операторам dist-upgrade и install), помещаются в каталог /var/cache/apt/archives/ - в дальнейшем их можно использовать для создания собственного локального репозитория или репозитория на CD/DVD. Недокачанные же части пакетов обретаются в каталоге /var/cache/apt/archives/partial/ - в случае обрыва соединения (или просто прерывания процесса apt-get upgrade по любой причине, в том числе и клавишной комбинацией Control+C) по восстановлении связи процедура скачивания и установки продолжается, как ни в чем не бывало.

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

$ sudo rm -Rf /var/cache/apt/archives/*

либо тем же apt-get с оператором clean или autoclean

Надо заметить, что в некоторых случаях apt-get с оператором upgrade не сможет выполнить обновление каких-то пакетов, о чем честно и сообщит перед запросом на подтверждение операции. Причины этому могут быть разные - например, конфликт новых зависимостей пакетов с каким-либо наличным софтом. На сей случай мы располагаем более радикальным средством - оператором dist-upgrade. Именно к нему следует прибегнуть, если мы обновляем старую версию дистрибутива до нового релиза:

$ sudo apt-get dist-upgrade

Эта команда просто тотально перепишет все наличные пакеты их обновленными версиями, одновременно разрешая и новые их зависимости (вплоть до удаления старых конфликтующих пакетов). Правда, и тут возможны коллизии типа описанной выше, но в большинстве случаев их можно проигнорировать - они, скорее всего, рассосутся при следующем апдейте и апгрейде. Если нет - эти коллизии придется разрешать вручную, на чем здесь останавливаться неуместно (возможные способы можно посмотреть в apt-howto из официальной документации проекта Debian (http://www.debian.org), в том числе и на русском языке.

Вот теперь можно взяться и за отдельные пакеты. Весь вопрос в том - за какие именно? Ведь дистрибутивные deb-пакеты вовсе не совпадают с пакетами авторскими - они намного более дробные. Например, каждый из авторских пакетов KDE, типа kdenetworks или kdegraphics, делится на множество мелких монофункциональных deb-пакетов. Хорошо, если пользователь наизусть знает те компоненты, которые ему необходимы - и именно в варианте пакетирования Ubuntu/Kubuntu (совпадающем с пакетированием Debian). А если нет? Тут на помощь ему и придет команда apt-cache, в первую голову - с оператором search, которая в качестве аргумента воспринимает любое ключевое слово. И в ответ на команду вида

$ apt-cache search ftp

последует список всех пакетов, в описании которых фигурирует ключевое слово ftp. Конечно, это доставит немного радости ввиду их изобилия, но со временем мы на примере аудио- и видеокодеков посмотрим, как использовать apt-cache search практически.

А пока - более примитивный пример. Пользователь, имеющий опыт работы с KDE, после установки Kubuntu с удивлением обнаружит отсутствие менеджера закачек kget - программы, очень облегчающей жизнь при интеграции ее с konqueror'ом. Однако, выполнив команду

$ apt-cache search kget

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

kget - download manager for KDE

который только и остается, что установить. Для чего следует вернуться к команде apt-get, имеющей специально предназначенную для этого цель install. Так что директива

$ apt-get install kget

благополучно скачает этот пакет и установит его в системе, при необходимости - со всеми обязательными (depends) зависимостями. Перед этим будет опять-таки выведен список подлежащих установке пакетов, объем скачиваемого материала и изменения в занятом дисковом пространстве. А также будет дан список пакетов, связанных с данным разными типами "мягких" зависимостей - пользователю останется только решить, нужны ли они ему.

Действие оператора install распространяется только на бинарные deb-пакеты. Если же возникнет необходимость получить их исходники (не зря же мы включили строки deb-src в файле /etc/apt/sources.list), то следует прибегнуть к оператору source, отвечающему за получение пакетов исходных текстов, и, возможно, опции -b, обеспечивающей их сборку. Хотя есть и другой способ сборки пакетов, о котором я расскажу в конце этого раздела.

Инструмент apt-get выполняет и удаление пакетов - для этого предназначен оператор remove. Примение его в "чистом виде" -

$ apt-get remove packagname

сохраняет настроечные файлы пакета. Однако добавление опции --purge производит полную очистку системы от всех его компонентов.

Очень ценна опция -i, обеспечивающая инверсию действия операторов. То есть команда

$ sudo apt-get remove packagname -i

установит пакет packagename, а команда

$ sudo apt-get install packagname -i

напротив, удалит его. Трудно переоценить значение этой опции при экспериментировании с большим количеством пакетов (а стадию выбора оптимального для себя инструментария проходит практически любой начинающий пользователь Linux): ведь для удаления кучи ненужных пакетов достаточно извлечь соответствующие команды из буфера истории и добавить в конец командной строки опцию -i. И аналогично поступить при случайном удалении нужного пакета.

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

Это - отдельный пакет, который нужно установить обычными образом:

$ sudo apt-get install apt-build

И в ходе установки - настроить его в диалоговом режиме. Первый вопрос при настроке - выбор степени оптимизации: облегченная (соответствующая флагу gcc -O1), средняя (флаг -O2, представляет выбор по умолчанию) и усиленная (-O3). Далее можно ввести дополнительные флаги gcc, если в них есть необходимость, указать опции для команды make. И последний вопрос - выбор процессора, для архитектуры x86 в списке доступных фигурируют "камни" от Pentium до Pentium-4.

Таким образом, при настройке apt-build можно очень точно задать условия компиляции. Если же для каких-либо программ их нужно изменить (например, повысить уровень оптимизации, добавить мультимедийные флаги, и так далее) - apt-build можно переконфигурировать обычным образом:

$ sudo dpkg-reconfigure apt-build

Синтаксически команда apt-build аналогична apt-get, включая операторы, требующие или не требующие аргументов, и, возможно, опции. Основные операторы - следующие:

  1. update - обновление списка доступных пакетов;
  2. upgrade - сборка обновленных пакетов;
  3. world - полная пересборка всей системы;
  4. update-source - апдейт пакетов исходников и их пересборка;
  5. build-repository построение репозитория пакетов (очевидно, что операторы пунктов 1-5 в аргументах не нуждаются);
  6. install - сборка и установка пакета (пакетов);
  7. source - скачивание и развертывание архивов исходников;
  8. info - получение информации о пакете, который будет собираться;
  9. build-source - сборка пакета без его инсталляции;
  10. remove удаление пакета (пакетов); операторы пунктов 6-9 требуют аргумента - имени пакета, над которым производится действие; аргументов таких может быть сколько угодно;
  11. clean-build и clean-sources - очистка каталогов, в которых выполняласть сборка, от ее пролуктов.

Таким образом, можно видеть, что инструмент apt-build, не смотря на сугубо пакетную природу использующих его дистрибутивов, имеет ничуть не меньшие возможности по индивидуалированной компиляции как отдельных программ, так и всей системы в целом, чем механизм make world и средства управления портами FreeBSD, или аналогичные интсрументы таких Source Based дистрибутивов Linux, как Gentoo (portage) или Archlinux (ABS). То есть при желании или необходимости, Kubuntu, как и любой клон Debian, может быть превращен в дистрибутив Source Based.

Я не ставил себе целью описать все возможности инструментария apt. За недостающими сведениями всегда можно обратиться к соответствующим man-страницам, упомянутому выше apt howto и к apt-faq проекта POSIX.ru (http://www.posix.ru/distro/apt_faq/).

Практика применения: мультимедиа в Kubuntu

Для начала должен признаться, что я ничего не понимаю во всяких там медиа-форматах, кодеках и движках - как для аудио, так и для видео. По жизни не требовалось. И впервые с необходимостью установки каких-то там движков и кодеков я столкнулся в дистрибутиве, общепризнано дружественном к пользователю - Kubuntu.

В Kubuntu для проигрывания аудио штатно предназначена программа amaroK. Звук можно слушать также с помощью универсального медиаплейера Kaffeine, основное назначение которого, однако, - воспроизведение видео. Так вот, сразу после установки, что называется, "из коробки", оба они в состоянии только запускать звуковые ogg-файлы, ни mp3, ни Real Audio их восприятию недоступны. Что же до второй задачи Kaffeine - воспроизведения видео, - то он неспособен сделать это даже с банальных avi'шек домашнего производства.

Столь нехорошее поведение объясняется отсутствием тех самых движков и кодеков. И связано с лицензионными соображениями. Дело в том, что алгоритмы, на которых основываются программы воспроизводства аудио/видео (например, mpeg-кодирования) запатентованы в тех странах, законы которых признают патенты на алгоритмы (или, скажем, законы природы). И майнтайнеры дистрибутивов, ориентированных на международное распространение (а разработчики Ubuntu/Kubuntu именно к тому и стремятся), вынуждены с этим считаться...

Благо законы нашей Родины, вопреки Салтыкову-Щедрину, в такой глупости до сих пор замечены не были, и мы можем слушать музыку или смотреть кино, не чувствуя себя интеллектуальными преступниками. Остается только обеспечить свое право возможностью его использовать, чтобы не получилось, как в старом советском анекдоте: Имею ли я право...? - Да, имеете. - А могу ли я...? - Нет, не можете.

Так вот, чтобы не только иметь право, но и мочь, нам и потребуется устанавливать эти самые кодеки/движки. Возникает вопрос - какие? На форумах в ответ обычно посылают к Ubuntu Guide (http://ubuntuguide.org) или его русскому переводу (http://ubuntu.ru/guide/). Не знаю, насколько этот документ поможет пользователю именно Ubuntu: у меня такое впечатление, что он несколько устарел, по крайней мере, русский перевод - точно. Но пользователю Kubuntu радости от него будет совсем мало. Поскольку в Ubuntu в качестве десктопа по умолчанию выступает GNOME, то и все описания в указанном источнике относятся к "гномической мультимедии". О KDE-приложениях там не сказано ни слова.

Конечно, можно обратиться и к документации собственно Kubuntu, например, к Kubuntu FAQ (http://kubuntu.org/faq.php). Однако оно - крайне лаконична, и предлагает решение только для обеспечения запуска mp3-файлов. Каковое сводится к

  1. установке пакетов akode-mpeg и gstreamer0.8-mad,
  2. директиве killall artsd для рестарта звукового сервера,
  3. перезапуску программы amaroK.

У кого как, а у меня (при встроенном чипсетном аудио от Nforce3) эти действия результат дали далекий от удовлетворительного. Конечно, amaroK после этого стал играть mp3-файлы - но с таким качеством, что лучше бы он этого не делал... Правда, в Kaffeine некоторые (далеко не все) mp'шки из моей коллекции воспроизводились более-менее ничего. Но ни о каком Real Audio речи не было ни там, ни там, да и проблему с видео это не решало. Попытки поиграть с настройками amaroK (в частности, сменой выходного модуля) положения не улучшали, а иногда и ухудшали - вплоть до выпадения программы в осадок.

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

Для начала займемся звуком, воспроизводимом посредством amaroK. Для чего устанавливаем akode-mpeg - ведь mpeg потребуется в любом случае. А потом посредством

$ apt-cache search amarok

смотрим, какие движки (engine) к нему можно подключить в принципе. Оказывается, следующие:

amarok-gstreamer - GStreamer engine for the amaroK audio player
amarok-arts - aRts engine for the amaroK audio player
amarok-engines - output engines for the amaroK audio player
amarok-xine - xine engine for the amaroK audio player

Поскольку опыт с GStreamer уже был - и неудачный, - остается опробовать amarok-arts и amarok-xine. Первый заслуженно пользуется дурной славой, так что остается единственный вариант - установка amarok-xine.

Результат превосходит все ожидания: amaroK начинает нормально играть не только mp3 и Real Audio, но и, в качестве бесплатного приложения, - классово чуждый WMA (в нем у меня всего несколько песен, но они мне дороги, и в других форматах их уже не будет). При этом в amaroK по умолчанию в качестве движка задействуется xine, модуль вывода становится в положение Автоопределение. Правда, Kaffeine - категорически отказывается что либо, кроме ogg-файлов - но не очень-то и хотелось, все-таки основное его назначение - крутить видео. А этого он пока тоже делать не хочет - в лучшем случае идет звук от моих самодельных avi'шек, в худшем - следует сообщение об отсутствии соответствующего кодека.

Изучение вывода команды

$ apt-cache search kaffeine

приводит к заключению, что нужно установить gstreamer0.8-mpeg2dec - после этого начинается показ фильмов, содранных с VideoCD - но без звука. Ставлю gstreamer0.8-mad - после этого в них звук. Но мои домотканные avi'шки по прежнему не прокручиваются - либо выдается ошибка в кодеке, либо просто идет звук без видео. Последняя надежда - устанавливаю gstreamer0.8-ffmpeg. Теперь, наконец, начинают крутиться и они, правда, некоторые - с рваным звуком. Однако это - небольшая потеря для человечества, так что эксприменты можно прекратить со спокойной душой.

Итак, подытоживаю: чтобы добиться воспроизводства всех потребных аудиоформатов (кроме умолчального ogg-vorbis, также mp3, Real Audio, WMA), достаточно выполнить следующую последовательность команд:

$ sudo apt-get install akode-mpeg
$ sudo apt-get install amarok-xine

А для просмотра видео, по крайней мере, в тех форматах, которые имеются у меня, нужно еще дополнительно сделать так:

$ sudo apt-get install gstreamer0.8-mpeg2dec
$ sudo apt-get install gstreamer0.8-mad
$ sudo apt-get install gstreamer0.8-ffmpeg

Все это установлено методом ползучего эмпиризма - так что комментарии и коррективы принимаются (и привествуются).

Практика сборки из исходников: забота о правильнописании

Еще одна проблема из числа локально зависимых, требующая решения, - проверка орфографии. С этим также некоторая напряженка. По умолчанию Kubuntu в этом качестве использует aspell - что естественно при юникодной локали (вторая распространенная проверка офрографии, ispell, насколько я знаю, с юникодом до сих пор не работает). Имеется и пакет с русским словарем для него, aspell-ru - то только для архитектуры i386. Так что на машине с интеловским процессором достаточно установить его через apt-get. А как быть с машиной на процессоре AMD64? Я придумал два решения.

Первое - через http://rpmfind.net/ отыскать более-менее свежий rpm-пакет для архитектуры AMD64 (в моем случае им оказался aspell-ru-0.99f7-2.x86_64.rpm для Red Hat), затем установить alien - трансформатор пакетов из одного формата в другой

$ sudo apt-get install alien

и его посредством преобразовать rpm в deb:

$ fakeroot alien aspell-ru-0.99f7-2.x86_64.rpm

Каковой и устанвливается обычным образом:

$ sudo dpkg -i alien aspell-ru-0.99f7-2.x86_64.deb

А вообще, проблема русского спеллинга в Kubuntu для AMD64 решается еще проще. А именно, достаточно просто автоматом построить соответствующий deb-пакет посредством apt-get -b source. Эта команда с указанным оператором (source) скачает пакет исходников (имя его фигурирует в качестве аргумента, в данном случае - aspell-ru, без указания версии и прочей атрибутики) из одного из доступных (и перечисленных в файле /etc/apt/sources.list) репозиториев. Автоматическая же сборка (компиляция, линковка) и установка пакета обеспечивается опцией -b.

Однако "лобовое" использование команды apt-get -b в отношлении пакета aspell-ru завершится сообщением об ошибке. Так что сначала нужно выполнить ряд подготовительных мероприятий. Разумеется, сборка aspell-ru, как и любого другого пакета, потребует наличия компилятора gcc и сопутствующего инструментария (binutils, make и так далее - все они легко вытягиваются apt-get'ом через взаимные зависимости).

В текущей версии Kubuntu по умолчанию задействован gcc текущей же, 4-й, ветки (хотя и gcc 3-й ветки также доступен). И имя он носит вполне логичное - /usr/bin/gcc-4.0. Одна беда, сценарии конфигурирования исходников при сборке предполагают, что компилятор должен именоваться gcc - и никак иначе. Так что первая попытка сборки завершится сообщением об отсутствии компилятора.

Простое и напрашивающееся решение - создать символическую ссылку:

$ ln -s /usr/bin/gcc-4.0 /usr/bin/gcc

Теперь с компилятором все нормально, но следуют жалобы на отсутствие других зависимостей. Благо их не так много, так что просто устанавливаем их такой серией команд:

$ sudo apt-get install dictionaries-common-dev
$ sudo apt-get install libmyspell-dev
$ sudo apt-get install ispell

После чего остается только собрать сам aspell-ru

$ sudo apt-get -b source aspell-ru

и подключить его к любимому текстовому редактору (nano там, или kate). Или просто запускать из командной строки:

$ aspell filename

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

Особенности "ядерного" пакетирования

Как было сказано в статье о том, что такое Linux, ядро - это почти такая же программа, как и все остальные. И в этом качестве также поддается управлению дистрибутивными средствами пакетного менеджмента. И в репозитории Ubuntu достаточно регулярно появляются бинарные пакеты прекомпилированных образов - так что при необходимости смены его версии (а необходимость такая возникает при появлении в ядре поддержки позарез нужной функции), достаточно установить его обычным образом:

$ apt-get install linux-image-2.6.XX-##-arch

Где XX - номер версии ядра (например, 2.6.15), ## - номер сборки пакета образа, а arch - архитектура, под которую этот образ сокмпилирован (например, 386 и 686 - под абстрактные процессоры Intel вообще и под Pentium Pro и выше, соответственно, k7 и amd64 - под обычный Atlhon и под Athlon 64-битный).

Установленное таким образом ядро будет поддерживать те его функции, которые показались необходимыми майнтайнерам. А как быть, если возникнет необходимость в ядре, сконфигурированном собственноручно? Конечно, времена, когда первым делом линуксоида после установки системы было - пересборка ядра, давно прошли. Нынче, по крайней мере в большинстве пакетных дистрибутивов, хорошим тоном считается пользовать прекомпилированное ядро, собранное майнтайнером (или одно из предоставляемых им ядер). И, надо признать, к тому есть немало оснований: в поставляемых с дистрибутивами, рассчитанными на широкие массы трудящихся, ядрах задействована модульная поддержка всех распространенных устройств, таких, как контроллеры жестких дисков SATA и ATA-RAID. А штатный способ загрузки их ныне - через специально сконфигурированный образ виртуального загрузочного диска initrd, - обеспечивает работу системы даже в том случае, если в качестве модулей поддерживаются загрузочные устройства и устройства, несущие корневую файловую систему.

Тем не менее, необходимость в перекомпиляции ядра иногда возникает. И причин к ней - две. Во-первых, модульная поддержка широкого круга устройств и загрузка системы через initrd, неизбежные для ядер инсталляционных дисков (действительно, не будешь же жестко встраивать в ядро поддержку всех возможных типов ATA- и SCSI-контроллеров или бесчисленных сетевых карт), далеко не идеальна для индивидуальной пользовательской машины. А во-вторых, модульная поддержка не всегда обеспечивает оптимальную работу устройств, в частности - максимальную производительность тех же жестких дисков.

В документации к Ubuntu и Kubuntu указаний по части сборки ядра, пожалуй, не найти. Однако тут впору опять вспомнить, что это - дети обширного Debian-семейства, и обратиться к документации по этому дистрибутиву. Каковая предлагает два метода выполнения этой процедуры - "как всегда" и "как лучше". На первом останавливаться не буду - он многократно описывался во всех книгах по Linux и бесчисленных Сетевых источниках. Скажу только, что он обычно сводится (при наличии исходников ядра, разумеется) к выполнению команды make menuconfigure, включению нужных и отключению ненужных опций через меню этой программы (каких именно - разговор совершенно особый, который мог бы составить предмет отдельной книги), собственно компиляции образа ядра и его модулей командами типа make и make modules, и установке получившихся бинарников в должные ветви файлового древа (как и куда - опять-таки, возможны варианты, на которых задерживаться не буду). В общем, любой линуксоид нашего поколения знает, как собирать ядро традиционным способом - не хуже, чем любой советский ребенок знал, как очищается политура, а наичнающим пользователям знать детали необходимости нет.

А вот метод "как нужно" - Debain-специфический, и избавляет пользователя от ряда деталей, копаться в которых ему совсем не обязательно. Он предусматривает для пересборки ядра специальный пакет - kernel-package, каковой и надлежит установить с помощью зазубренных ранее волшебных заклинаний:

S apt-get install kernel-package

Заодно следует обзавестись и сопутствующими пакетами - debhelper, modutils и libncurses5-dev (последний нужен для генерации меню по команде make menuconfig). И еще - пакетом fakeroot, который отвечает за запуск команд в имитируемом root-окружении.

Далее, естественно, требуются исходники ядра. В качестве таковых можно взять последнюю версию ядра канонического, с http://www.kernel.org, можно - дополнить их патчами других разработчиков. А можно - просто пересобрать штатное ядро дистрибутива. В последнем случае нужно установить соответствующий пакет с исходниками, например:

S sudo apt-get install kernel-source-2.6.XX

Обращаю внимание, что имя пакета, содержащее исходники ядра, указывается с номером версии последнего. Кроме исходников, этот пакет содержит Debian-специфичные патчи, правда, нужные, насколько я понял, только для создания initrd.

И еще: почти все последующие процедуры потребуют привилегий администратора, так что, дабы не прибегать к sudo перед каждой, их можно получить на все время "ядерных" упражнений - напоминаю, как:
$ sudo -s -H

Результатом выполнения последней команды будет появление в каталоге /usr/src тарбалла исходников. Переходим туда и распаковываем тарбалл обычным образом:

S tar xjvf kernel-source-2.6.XX.tar.bz2

Да, в промежутке можно отредактировать файл /etc/kernel-pkg.conf - правда, кроме собственного имени и электронного адреса, вписывать в него вроде нечего. Следующий этап Debian-метода построения ядра выполняется, "как всегда". То есть - переходом в соответствующий каталог

S cd /usr/src/linux-source-2.6.12/

копированием в него нашего рабочего конфига ядра:

S cp /boot/config-2.6.12-1-amd64-generic .config

(дабы не начинать конфигурирование с нуля, а лишь вносить необходимые коррективы) и запуском команды

S make menuconfig

Процедуру конфигурирования описывать не буду - в контексте нынешней темы скажу только, что, в целях избавления от initrd, необходимо жестко встроить в ядро поддержку всего, имеющего отношение к старту системы. То есть - контроллера "несущего" систему диска и типа файловой системы, содержащей корень файлового древа. Неплохо также избавиться от поддержки "лишних" чипсетов и прочего не имеющего быть оборудования.

Далее руководство в приказном порядке рекомендует выполнить очистку дерева исходников:

$ make-kpkg clean

что требуется для уничтожения следов от номеров предыдущих ревизий ядра - следующей командой мы определим свою их нумерацию. А командой этой будет

$ fakeroot make-kpkg --append_to_version \
        -amd64 --revision=rev.01 kernel_image

Здесь fakeroot создает "правильное" root-окружение (то есть команда может быть запущена от имени пользователя), make-kpkg - собственно программа для построения бинарного "ядерного" пакета, ее опции предписывают добавлять к имени пакета номер версии ядра, архитектуру, под которую оно собиралось, и номер ревизии, то есть нашей собственной сборки, а kernel_image - имя целевого пакета.

В результате указанной директивы сначала происходит компиляция ядра, а потом из него собирается самый обычный deb-пакет вида kernel-image-2.6.12-amd64_rev.01_amd64.deb, помещаемый в каталог /usr/src. Так что дело остается за малым - установить его обычным же образом:

$ cd ..
$ dpkg -i kernel-image-2.6.12-amd64_rev.01_amd64.deb

При этом файл образа ядра и соответствующий ему System.map будут не только скопированы куда следует (то есть в каталог /boot - если он составляет отдельную ветвь файлового древа, нужно не забыть предварительно его примонтировать!), но и внесены изменения в файл конфигурации загрузчика (например - в /boot/grub/menu.lst, если таковым выступает GRUB): новое ядро займет умолчальную позицию в его меню, старое же сохранится в качестве резервного.




Комментарии

Страницы комментариев: 1 :: 2 :: следующая

sergey, Sun Jun 21 14:08:34 2009:
Залез не за тем, что написано, а то, что написано и так знаю(((
Solomon243, Mon Mar 10 23:27:42 2008:
Понравилося. Узнал, что хотел. Плюс стопиццот!
ОНОним, Sat Mar 8 23:16:32 2008:
Ф ПЕТЕРКЕ Супер )))
Sedoj, Fri Feb 8 12:12:52 2008:
Спасибо, хорошо написано
victor, Sat Nov 24 15:56:12 2007:
Этапять! Жжошь!
Пеши исчо!
vladimirfx, Wed Sep 19 15:32:48 2007:
Хотя большенство написанного мне было известно, дочитал статью до конца с удовольствием!
Спасибо!
аноним, Tue Sep 18 19:14:46 2007:
Да, достаточно полезная статья.
аноним, Tue Sep 18 00:10:47 2007:
лучший мануал, когда либо прочитанный мной.
Автору - респект!
vladimirfx, Sat Sep 15 02:25:48 2007:
Хотя большенство написанного мне было известно, дочитал статью до конца с удовольствием!
Спасибо!
аноним, Fri Sep 7 10:58:16 2007:
класс! спасибо =)

Страницы комментариев: 1 :: 2 :: следующая

Комментарии заморожены.

Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds