Archlinux: гармония гибкости и простоты

Этот мемуар, как явствует из его названия, посвящен дистрибутиву Archlinux. Еще один дистрибутив... - с выражением скуки на лице может сказать читатель, имеющий некоторый опыт общения с Linux. И будет, конечно, прав: сколько таких описаний довелось в последнее время видеть любому, мало-мальски интересующемуся этой операционкой? И тем не менее, рискну продолжить. Ибо Archlinux обладает некоторыми особенностями, ставящими его в уникальное положение в ряду прочих дистрибутивов. Что я и надеюсь обосновать далее.

[Алексей Федорчук (alv AT ginras.ru)]

Содержание

Обзор дистрибутива

Одна из превалирующих тенденций Линукс-дистрибутивостроения последних лет - распадение дистрибутивов на две идеологически различные линии. С одной стороны, это - пакетные дистрибутивы, развитие которых идёт по пути быстроты развёртывания и упрощения настройки. С другой - дистрибутивы Source Based, генеральной линией которой является рост гибкости настроек и их индивидуализации.

За все в этой жизни приходится платить. И расплатой за простоту установки пакетных дистрибутивов является их статичность и даже, я бы сказал, косность. А дистрибутивы Source Based для полной реализации заложенной в них гибкости требуют - нет, даже не более высокой квалификации, а в первую очередь большого резерва времени и, что немаловажно в наших условиях, хорошего (и дешёвого) канала связи.

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

Типичным примером такого промежуточного дистрибутива и является Archlinux. Он возник относительно недавно - версия за номером 0.1 датируется 2002/03/11, генетически отпочковавшись от CRUX - весьма своеобразной системы, представляющей собой предельно минималисткий, но полнофункциональный дистрибутив: в 200 Мбайт iso-образа его создатель, Пер Лиден, умудрился утрамбовать не только Base Linux, но и оконную систему X, оконный менеджер WindowMaker, основные приложения для консоли и Иксов. Что достигается жесточайшим усекновением любого балласта - от излишней, по мнению Пера, документации (info- и html-страниц) до отказа от поддержки NLS в базовой комплектации.

Впрочем, CRUX - совсем отдельная история: это скорее конструктор для построения системы в соответствие с собственными потребностями, нежели готовый к употребленпию дистрибутив. Который поэтому лег в основу ряда потомков, одним из которых (впрочем, весьма отдалившимся от прототипа) и является Archlinux. Он разрабатывается интернациональной командой во главе с Джаддом Вайнетом (Judd Vinet), официальный сайт проекта - http://www.archlinux.org. Как и положено, дистрибутив свободно доступен по ftp - в виде ISO-образов CD и отдельных пакетов. Таким образом распространяется стабильная его версия (на момент сочинения этих строк - 0.7), текущая же (current), как и положено, находится в стадии перманентной разработки.

Образ установочного диска стабильной версии существует в двух вариантах - полном (500- 600 мегабайт, в зависимости от версии) и базовом (около 200 Мбайт). Первый представляет собой полнофункциональный дистрибутив, включающий, кроме таких краеугольных компонентов, как ядро, gcc, glibc иже с ними, также систему X, KDE, KOffice, необходимый набор графических и мультимедийных приложений и средств администрирования.

Базовый вариант полностью отвечает своему названию, представляя собой Base Linux почти в чистом виде - примерно в том, что был описан в этом сочинении. В отличие от CRUX, включение в базовую комплектацию gettext обеспечивает поддержку NLS "из коробки". Хотя в отношении излишней документации Archlinux столь же безжалостен, обнаруживая в своем составе исключительно традиционные man-страницы.

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

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

Многое из недостающего в current можно отыскать среди пакетов ветки extra. Они не входят непосредственно в состав дистрибутива и собираются независимыми разработчиками-энтузиастами (контрибьюторами). Поэтому состав их относительно случаен: каждый из таких контрибьюторов вносит в репозиторий свои любимые программы.

Число неофициальных пакетов также не поражает воображения, однако и их обновление весьма оперативно: здесь сборки самых свежих версий интегрированных сред KDE и GNOME, их приложений, и многого другого, нужного в обыденной жизни.

Короче говоря, репозиторий Archlinux по насыщенности последними достижениями Open Sources далеко уступает Debian, Sysiphus, distfiles FreeBSD или Gentoo. Однако, как я покажу позднее, сила его - не в этом. А недостаток пакетов, требуемых для какой-то специфической задачи, очень легко восполняется. И компенсируется продуманностью, сбаллансированностью и отлаженностью.

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

Неофициальная документация включает в себя весьма информативную подборку часто задаваемых вопросов (краткий FAQ есть и в официальной части) и пару How-to, посвященных колоризации процесса загрузки и созданию т.н. bootsplash. Впрочем, по откровенному признанию автора второго документа, оба они рассчитаны на пользователей, располагающих "some time to kill"...

До недавнего времени единственным способом получения дистрибутива Archlinux было скачивание из Интернета iso-образа установочного диска с дальнейшей актуализацией системы по Сети же. Однако ныне Линукс Центр приступает к изданию и распространению этого дистрибутива в виде самодостаточного комплекта. Он включает оригинальный установочный CD-диск текущей версии и DVD-диск с дополнительными пакетами ветвей current и extra, тарбаллом дерева ABS (Archlinux Building Systems), оригинальным англоязычным руководством по установке, настоящим мемуаром, кириллическими шрифтами и раскладкми клавиатуры для консоли. Кроме того, здесь же можно найти iso-образ Archie LiveCD - дочернего проекта Archlinux, созданного на его базе.

Прелюдия к установке

Знакомство с любым дистрибутивом начинается с его установки. Однако я сознаю, что пока не убедил читателя - стоит ли ему выполнить эту процедуру в отношении Archlinux. И потому опишу вкратце ее основные особенности.

Оба варианта установочного диска Archlinux являются загрузочными (кого нынче этим удивишь?). И для получения впечатления от системы достаточно любого - более того, по причинам, которые станут ясны в дальнейшем, я бы отдал явное предпочтение базовому варианту. Тем паче, что качать 200 Мбайт быстрее, чем 600 (еще бы).

Кое-что о системных требованиях. Все пакеты дистрибутива оптимизированы под абстрактный процессор i686 (сборка с флагами gcc -O2 и -march=i686). Так что попытка установить его на машине с процессором ниже Pentium Pro успехом не увенчается. То есть для гальванизации устарелого "железа" система не подходит. С парой оговорок: во-первых, существует неофициальная версия, собранная для процессоров семейства i586, и, во-вторых, при наличии доступа к Arch-машине собрать комплект под любой x86-совместимый процессор, поддерживаемый текущей версией gcc, не составит большого труда.

Зато, ввиду все той же ориентации на пользователя, хотя бы в минимальном объеме знакомого с Linux, прекомпилированное ядро, загружаемое с установочного диска по умолчанию, поддерживает не только широкий спектр оборудования (вплоть до ATA RAID), но и множество типов разделов (в частности, программные RAID-массивы от линейного до уровня 5, систему логических томов LVM) и файловых систем (ext2, ext3, reiserfs, XFS). Благодаря этому, при наличии на машине какого-либо дистрибутива Linux, в процессе установки можно обращаться к существующим данным - конфигурационным файлам, документации (в том числе, подгрузив соответствующий шрифт, и русскоязычной), архивам программ и т.д.

Уяснив все это (а кое-что из сказанного может пригодиться при инсталляции), вставляем диск (для определенности - базовый, в дальнейшем я буду исходить из этого умолчания) в привод и перезагружаемся, определив по ходу дела соответствующие установки в BIOS. Через считанные секунды на экране появляется приглашение boot:, позволяющее при необходимости задать параметры загрузки, как то: загрузку ядра с поддержкой SCSI ("умолчальное" ядро с CD поддерживает только IDE-интерфейс), или загрузку уже установленной системы Archlinux (что позволяет использовать установочный CD в качестве большой rescue-дискеты). Впрочем. на данном этапе все это вряд ли актуально. поэтому просто жмем Enter для продолжения загрузки (сама по себе она не продолжится, ожидая реакции пользователя).

Несмотря на обилие включенных в загружаемое ядро опций, старт системы происходи быстро. И по завершении его мы наблюдаем приглашение командной строки оболочки ash (несколько, однако, функционально расширенной - с автодополнениями,`историей команд и прочими облегчающими жизнь мелочами). Автоматически (без запроса пароля) авторизовавшись в качества суперпользователя, мы получаем в свое распоряжение еще три (кроме текущей) виртуальные консоли. Для активизации любой достаточно обычной комбинации клавиш Atl+F2[F3,F4] и нажатия клавиши Enter. А перейдя на пятую консоль, в последующем можно будет видеть вывод сообщений о ходе установки.

Одна из дополнительных консолей потребуется сразу же: на нее можно (и даже, я сказал бы, нужно) загрузить с CD руководство пользователя - текстовую копию официальной html-документации с сайта проекта:

$ less /arch/archdoc.txt

И, следуя мудрому правилу POSIX'ивистов, внимательно изучить - оно, как я уже отмечал, сеет разумное, доброе, вечное.

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

$ /arch/setup

в ответ на которую выводится синенькая псевдографическая панель главного меню, навевающего воспоминания о Slackware. Врочем, разработчики сами подчеркивают, что Slackware была вторым, после CRUX, источником идей, реализованных в Archlinux.

Однако главное меню Arch'евского установщика еще более лаконично, и содержит лишь семь пунктов:

  • подготовка диска;
  • выбор пакетов;
  • установка пакетов;
  • установка ядра;
  • конфигурирование системы;
  • установка загрузчика;
  • выход.

Рассмотри эти пункты подробнее.

Подготовка диска

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

Создание разделов может быть выполнено в автоматическом (при этом задействуется весь диск с уничтожением его содержимого) или полу-ручном режиме - посредством утилиты cfdisk). Отказавшись от создания разделов, можно использовать ранее существующие. Однако подготовить разделы полностью вручную (в другой консоли) не удастся - вызов команды cfdisk при этом дает сообщение об ошибке (а, скажем, программы fdisk в установочном наборе команд просто не предусмотрено).

При создании файловых систем сначала запрашивается раздел, отводимый под своппинг, потом - тот, на котором планируется разместить корневую файловую систему и предлагается выбор ее типа - ext2, ext3 или reiserfs (последний отмечается по умолчанию). Далее при желании (и наличии разделов) можно заказать создание и монтирование таких ветвей файлового древа, как /boot, /usr, /var, /home. Интересно, что, как станет ясно в дальнейшем, ветвь /tmp по умолчанию предлагается разместить на tmpfs - при обычных ныне объемах памяти вполне оправданное, я бы даже сказал - прогрессивное, решение.

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

Впрочем, все эти ограничения в дальнейшем легко обходятся, особенно если ограничиться базовым набором пакетов (и это - первый довод в пользу выбора базового варианта установочного CD). Как будет сказано позднее, вся базовая установка Archlinux укладывается примерно в 400 Мбайт. Так что для начала можно ограничиться полугигабайтным корневым разделом, а по окончании инсталляции (после перезагрузки) вынести на логику или на программный RAID все желаемые ветви файловой системы (все равно, размещение на них корня файлового древа - идея не из самых здоровых).

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

В случае единственного диска, отдаваемого в распоряжение Archlinux целиком, опираясь на принципы, которые я попытался сформулировать здесь), можно предложить такую схему разметки диска:

Корневой раздел		256 Мбайт
/usr			4096 Мбайт
/opt			2048 Мбайт
/var			1024 Мбайт
/var/abs		1024 Мбайт
/var/cache/pkg		1024 Мбайт
/var/cache/src		1024 Мбайт
/home			сколько осталось

Назначение корневого каталога, каталогов /usr и /home понятно. Необходимость вынесения каталога /opt в отдельный раздел обусловлена тем, что в Archlinux он служит для помещения таких объемных пакетов, как Qt, KDE, Gnome, OpenOffice, Mozilla. Обособление каталога /var призвано предотвратить возможность переполнения корневой файловой системы всякого рода системными сообщениями. Ну а такие ветви каталога /var, как /var/abs, /var/cache/pkg, /var/cache/src, предназначены для портоообразной системы ABS (Archlinux Building System), скачиваемых из Сети бинарных пакетов (в частности, при процедуре синхронизации) и исходников портированных программ, соответственно; почему их также целесообразно разместить на отдельных разделах. Таким образом мы воплощаем в жизнь принцип отделения легко восстановимых частей файловой системы от того, что было скачано из Сети непосильным трудом...

Кроме этого, при использовании в качестве загрузчика GRUB (а именно так принято в Archlinux по умолчанию) разработчики его настоятельно рекомендуют вынесение на отдельный раздел (размером в пару десятков мегабайт) каталога /boot. Если же спомнить о необходимости (ну, пусть желательности, как станет ясно из следующего абзаца) еще и раздела для своппинга, становится ясным, что первичных разделов на все про все явно не хватит. Так что первичные разделы следует отвести только под /boot и корень, а под все остальные ветви файлового древа задействовать логические разделы.

Обратим внимание, что в предложенной схеме нет места для раздела под каталог /tmp: как уже было сказано, в Archlinux по умолчанию в эту точку монтируется файловая система в оперативной памяти - tmpfs. А поскольку для каталога /tmp при определенных условиях существует вероятность быстрого заполнения всякими продуктами жизнедеятельности - становится ясной желательность раздела подкачки даже при очень большом объеме оперативной памяти. Ведь tmpfs использует как физическую, так и виртуальную память.

Завершив заказ точек монтирования и файловых систем, следует (обязательно через пункт Done) вернуться в меню подготовки диска. Собственно, в этот момент реально и произойдет форматирование разделов, создание точек монтирования и собственно монтирование файловых систем. В этом легко убедиться командой mount в одной из виртуальных консолей до и после выхода из данного пункта меню. В последнем случае мы увидим, что все заказанные нами файловые системы окажутся смотированными в указанные подкаталоги каталога /mnt, выступающего в качестве будущего корня (/mnt/boot, /mnt/usr и так далее).

Выбор и установка пакетов

Теперь можно вернуться в главное меню и перейти к пункту выбора пакетов. Впрочем, при использовании базового CD особо напрягаться по этому поводу не стоит: перед нами предстают только компоненты Base Linux в весьма пуристическом подборе. Единственное, что тут можно урезать - это bin86, если не предполагается загрузка через Lilo (ну и сам Lilo, разумеется - умолчальным загрузчиком в Archlinux выступает GRUB), инструментарий для неиспользуемых файловых систем (например, JFS) и программных RAID. А также - vim, если пользователь испытывает стойкое отвращение к этому редактору. Да и любителям vim все равно придется его потом пересобирать - штатно он собран без поддержки langmap, что весьма осложняет жизнь в кириллическом окружении. Только нужно учесть, что другого редактора при базовой установке после перезагрузки у нас не будет - до тех пор, пока мы не установим или не соберем его собственноручно.

Если же установка идёт с CD в полном варианте - подумать стоит. Потому как тогда доступными оказываются не только Base Linux, но и Иксы, и WindowMaker, и вообще очень многое из того, что требуется для минимально комфортной работы (некоторые решат - что вообще все). Правда, установлены они будут из прекомпилированных бинарников, собранных согласно представлениям авторов дистрибутива. В частности, links не будет поддерживать графику, vim - langmap, и так далее. Впрочем, как я уже сказал, все это определяется задачами (да и исправимо в дальнейшем).

Кроме того, полная установка текущей версии дает большое количество устаревших пакетов (относительно устаревших - заведомого старья в Archlinux все равно не найти). Что, впрочем, также поправимо - и при некоторых условиях, прямо сейчас. Я забыл сказать, что при запуске инсталлятора пользователю предлагается выбор метода установки - с CD или через FTP. И если имеется хороший коннект, второй вариант позволяет сразу же установить пакеты ветки current. Правда, удаленная установка (описанная далее в соответствующем разделе) работает только через сеть - использование ppp-соединения для этой цели не предусмотрено (а оно нам нужно?).

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

Установка ядра

Установка ядра и будет следующим шагом. Здесь возможны четыре варианта: выбор из двух прекомпилированных ядер - одно с поддержкой IDE-устройств, второе - также и SCSI, сборка ядра собственного и отказ от установки ядра вообще (позднее я скажу, при каких обстоятельствах это может иметь резон).

Установить прекомпилированное ядро - самый простой (и, при отсутствии специфических требований, разумный) вариант. Не скажу за scsi-ядро, не пробовал по причине отсутствия соответствующего "железа", а вот ядро ide собрано более чем разумно: включена поддержка всего, что есть в загрузочном ядре с CD (ATA RAID и RAID программный, LVM, все необходимые файловые системы), плюс доступны USB-устройства (флэш-накопители заработают без дальнейших телодвижений, а USB-мышь потребует только установки gpm и несложного конфигурирования), эмуляция ide-scsi (для записи CD-R/RW), звуковые карты подключены в качестве модулей. Из замеченных минусов - только отсутствие поддержки SATA (как, впрочем, и в ядре установочного диска - будем надеяться, в следующей версии широкое распространение дисков с этим интерфейсом будет учтено могучим ураганом).

Конечно, конфигураиця ядра, как обычно в таких случаях, получается несколько избыточной. Но это вполне компенсируется быстротой установки и ее простотой: кроме собственно записи загружаемого образа в каталог /mnt/boot (под именем vmlinuz - в дальнейшем это будет важно), инсталлятор также установит в должные места все наличные модули и необходимые заголовочные файлы. Правда, исходников ядра при этом в /usr/src не обнаружится. Но это - не беда, Archlinux использует каноническое ядро vanilla, без всяких дистрибутив-специфичных патчей, которое легко получается с http://www.kernel.org. Да и на диске имеется - в качестве отдельного тарбалла.

Тем не менее, если все-таки есть желание сконфигурировать ядро собственное - инсталлятор предоставляет и такую возможность. По выборе соответствующего пункта из меню появляется серия панелей с исчерпывающими инструкциями, как именно это сделать. После чего ядро автоматически распаковывается в каталог /mnt/usr/linux - остается только

  1. перейти в свободную консоль,
  2. подмонтировать необходимые файловые системы, такие как devfs и procfs:
  3. 	$ mount -t devfs devfs /mnt/dev ;
    	$ mount -t proc proc /mnt/proc
    	
  4. выполнить операцию смены корня:
  5. 	$ chroot /mnt /bin/bash
    	
  6. зайти в дерерво исходников относительно нового корня:
  7. 	$ cd /usr/src/linux
    	
  8. сконфигурировать ядро обычным способом:
  9. 	$ make menuconfig
    	
  10. и собрать его столь же обычной последовательностью команд:
  11. 	$ make dep && make bzImage && \
    	make modules modules_install
    	

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

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

Итак, отказываемся от установки ядра (именно на сей предмет и предусмотрен четвертый пункт соответствующего меню), переходим в свободную консоль, монтируем нужный раздел или иной носитель, типа USB-драйва (благо они доступны на стадии инсталляции системы), например, в каталог /mnt/mnt, и разворачиваем заблаговременно размещенный там тарбалл с исходниками ядра. Здесь - первая тонкость: команда tar из установочного окружения не поддерживает опции -j, а команда bunzip2 вовсе отсутствует, поэтому распаковка выглядит примерно следующим образом:

$ bzip -dc /path/linux-2.4.22.tar.bz | tar xpv

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

$ chroot /mnt /bin/bash

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

$ make dep && make bzImage modules

Теперь образ ядра копируем, куда следует:

$ cp arch/i386/boot/bzImage /mnt/boot/[vmlinuz]

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

Но и это еще не все: по завершении процедуры мы пока остаемся без заголовочных файлов. А их следует брать не из ядра рабочей версии, а из того, под которым собиралась установленная в системе glibc. Так что все равно приходится распаковывать штатный ядерный тарбалл и копировать необходимые файлы и подкаталоги из /mnt/usr/src/linux-2.6.X/include в /mnt/usr/include.

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

Стартовые файлы и загрузчик

А пока надлежит все-таки закончить установку. От чего нас отделяет два шага. Первый из них - конфигурирование системы. По выборе этого пункта будет предложено сначала выбрать текстовый редактор для этой процедуры (выполняемой именно посредством этого инструмента) - vi или nano. Здесь замечу, что вы не на "ты" именно с первозданным vi (а не любым из его продвинутых клонов типа vim) - лучше за него и не браться, остановившись на тривиальном, но простом nano.

Далее перед нами предстает подменю со списком файлов, доступных для конфигурирования - rc.conf (главный конфигурационный файл в BSD-стиле), grub.conf или lilo.conf (разумеется, править нужно только тот, что соответствует выбранному загрузчику), hosts, fstab, modules.conf и resolv.conf. Понятно, что абсолютно обязательно просмотреть файл конфигурации загрузчика и fstab, прочие можно отложить на потом. Хотя именно в этих двух файлах умолчальные записи, внесенные инсталлятором, практически соответствуют тому, что нужно (особенно если ядро устанавливалось штатным способом). Разве что в fstab можно добавить, например, swap-раздел на втором диске, ну и прочие полезные мелочи (типа опций notail,noatime,nodiratime для reiserfs, исключить /boot из автоматического монтирования при загрузке через GRUB, и тому подобное).

Небесполезно и поправить rc.conf, так как здесь можно установить

  1. правильный часовой пояс:
    	TIMEZONE=Europe/Moscow
    	HARDWARECLOCK="UTC"
    	
    или, если системные часы установлены по местному времени, во второй строке следует поставить local;
  2. прописать модули для автоматической загрузки (например, ide-scsi и usb-storage);
  3. при необходимости указать сетевые параметры и вообще скорректировать стратовые сервисы:
    	DAEMONS=(cron gpm ...)
    	
    как это исчерпывающим образом описано в комментариях;
  4. задать русскую раскладку клавиатуры - в дистрибутиве они имеются в полном комплекте, например:
  5. 	KEYMAP=ru4m
    	
  6. определить шрифт консольного вывода, допускающий воспроизведение кириллицы:
  7. 	CONSOLEFONT="LatArCyrHeb-16 -m koi8-r_to_uni"
    	

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

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

Вот и все. Покидаем инсталлятор, перезагружаемся, извлекая по ходу дела CD - и наслаждаемся, или восхищаемся, нашим новым дистрибутивом...

Особенности установки по FTP

Как уже говорилось, текущая версия Archlinux, доступная с установочного CD, может содержать не самые последние версии пакетов. В репозитории же этого дистрибутива пакеты обновляются со страшной научно-фантастической силой - и у пользователя может возникнуть резонное желание приобщиться к последним достижениям Linux'овой мысли.

Конечно, Archlinux обладает мощной и очень простой в использовании системой апдейтинга - ABS. Однако ее использование связано с компиляцией пакетов, что требует немалого времени.

Далее, пакетный менеджер Archlinux, pacman, дает возможность тотального (и почти мгновенного) обновления системы из прекомпилированных бинарников. Однако при кардинальной смене версий некоторых базовых пакетов тут можно ожидать всякого рода шероховатостей. Так, в свое время, после выхода ncurces-5.4, мне так и не удалось собрать zsh и joe с поддержкой UTF-8.

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

Начальные шаги FTP-установки не несут с собой ничего специфичного - это а) загрузка с установочного CD, б) запуск программы setup, в) разбиение диска на разделы, г) создание файловых систем и д) их монтирование. Далее достаточно вернуться в главное меню, перейти в его пункт выбора пакетов (Packages Select) и там на вопрос об источнике инсталляции бестрепетно ответить - FTP.

Вполне ожидаемо, что первое предложение после такого безрассудства - настроить сеть. А нужно сказать, что в настоящее время сетевая установка Archlinux предусматривается только из локалки с подключением к Интернету - по модему выполнить ее невозможно ввиду отсутствия поддержки ppp в установочном ядре, а указаний об установке с NFS я в документации не нашел.

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

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

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

В правдивости сообщения инсталлятора можно убедиться тут же, обратившись к выбору пакетов, предваряемому выбором зеркала. Сначала происходит синхронизация их списка с репозиторием: по умолчанию в качестве такого предлагается current, то есть самые современные версии (хотя вручную можно установить и stable, но в этом случае затея теряет смысл - его пакеты будут идентичны имеющимся на CD более чем полугодичной давности). Затем предлагается список категорий: base, daemons, devel, editors, kernels, lib, multimedia, network, office, system и X11. Бросается в глаза отсутствие категорий KDE и GNOME - ныне они изъяты из официальной части дистрибутива, хотя, как будет сказано далее, доступны в виде пакетов категории extra.

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

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

Состав пакетов в current-версии может отличаться от такового с установочного CD, поэтому задержу на нем некоторое внимание. Для начала, категория base выглядит несколько распухшей, в первую очередь, за счет новомодных пакетов типа udev. Тем не менее, почти все в ней представляется необходимым: чуть ли не единственный оправданный кандидат к отчислению - один из загрузчиков, grub или lilo, в соответствие с личными предпочтениями. Ну и reiserfsprogs - в случае стойкой неприязни к этой файловой системе. Еще кандидат на выброс - raidtools, поскольку даже при наличии потребности в Soft RAID для этой цели, по моему мнению пользователя, проще использовать mdadm (имеющий место быть в категории system.

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

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

В категории multimedia заслуживает быть отмеченным alsa-driver (вкупе с прочим alsa-инструментарием). Именно его наличие - дополнительный стимул к выбору прекомпилированного ядра, ведь при сборке ядра собственного пришлось бы пересобирать модули поддержки звука.

Наконец, X11. Здесь "кардинальное" изменение выражено в замене XFree86 на идеологически выраженный Xorg. Правда, и "неправильный" XFree86 после инсталляции становится доступным как пакет категории extra. Впрочем, Xorg на деле оказывается совсем не страшным (хотя по началу немного непривычным), так что выбор между X-серверами можно делать чисто волевым усилием (если не вдаваться в тонкости лицензионной политики, остающиеся для меня не совсем понятными)

Ознакомившись внимательно со всем списком, производим окончательный выбор и жмем на OK. Некоторое время происходит проверка зависимостей выбранных пакетов, а затем, с той или иной степень вероятности, сообщение о их нарушении. Приходится возвращаться в меню выбора категорий и далее - пакетов, и так до победного конца. Есть, конечно, возможность продолжить установку на свой страх и риск, но прибегать к ней, ИМХО, не следует: зависимости в пакетах Archlinux описаны по принципу здорового минимализма. Хотя в принципе, если в дальнейшем предполагается пересборка конкретного пакета в еще более минималистском варианте, от кое-каких зависимостей можно и отказаться.

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

Наконец, наступает счастливый момент окончания скачивания - в силу особенностей формата пакетов и исключительного быстродействия пакетного менеджера Archlinux временем на собственно установку можно пренебречь.

Теперь нужно установить самый главный компонент - ядро системы. Это - такой же пакет, как и все остальные (из категории kernels), и устанавливается также - выбором из списка, включающего две пары альтернатив - прекомпилированные ядра ветвей 2.4.X и 2.6.X, с поддержкой SCSI или без оной, соответственно. Нештатно возможна и сборка собственного ядра, как это описывалось ранее.

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

Первый из сетевых интерфейсов, внутренний (т.н. loopback), собственно к сети отношения не имеет, однако позволяет, в частности, организовать web-сервер на локальной машине. Он требует внесения в rc.conf такой строки:

lo="lo 127.0.0.1"

За обычный же сетевой протокол отвечает строка вида:

eth0="eth0 ... "

В оригинальном файле в этой строке в качестве примера приведены IP-адрес, сетевая маска и тому подобные параметры. Однако в реальной сети с DHCP-сервером ей достаточно придать такой вид:

eth0="dhcp"

после чего обеспечить активизацию обоих интерфейсов (что уже сделано по умолчанию):

INTERFACES=(lo eth0)

Строки, определяющие gateway и ROUTES, при использовании DHCP-сервера, насколько я знаю, не нужны.

А вот строка, обеспечивающая загрузку демонов, важна. По умолчанию она имеет вид:

DAEMONS=(syslog-ng hotplug !pcmcia network netfs crond)

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

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

Однако стремление к идеалу - неотъемлемая черта пользователя POSIX-систем. И для такового далее я постараюсь продемонстрировать тот самый цимес, который придаёт неповторимое своеобразие дистрибутиву Archlinux. - систему управления пакетами и, особенно, систему построения оных.

Pacman - базис пакетного менеджмента

Для начала - об управлении пакетами готовыми. Archlinux - не не является в полном смысле слова дистрибутивом Source Based, подобно Gentoo или, тем более, Linux from Scratch. Ибо основная форма его дистрибуции - все же в виде набора прекомпилированных пакетов. Видом эти пакеты похожи на обычные архивы *tar.gz:

package##ver##rel.pkg.tar.gz

Здесь package - имя пакета, ##ver - номер его версии, присвоенный его разработчиком, ##rel - номер реализации, то есть сборки конкретного бинарника, даваемый уже майнтайнерами Archlinux, аббревиатура pkg свидетельствует, что мы имеем дело с прекомпилированным пакетом Archlinux, а не c абстрактным тарбаллом, ну а два последние суффикса понятны без комментариев...

При ближайшем рассмотрении оказывается, что пакеты Archlinux похожи на тарбаллы не только видом, но и нравом. Формат их - прост до предела, это именно чистое за-tar'енное дерево, сжатое gzip'ом, не содержащее никаких инсталляционных скриптов, и вообще никакой метаинформации: только сам исполняемый бинарник (бинарники), предназначенный для помещения в каталог /usr/bin (за исключением тех программ, которым резонно находиться в /bin, /sbin или /usr/sbin), сопровождаемый в необходимых случаях конфигами (для каталога /usr/etc) и библиотеками (для /usr/lib), а также man-документацией.

Как и его прародитель CRUX, Arch признает только тётю Маню, info и прочая документация из пакетов вычищена.

Средство для управления этими просто построенными пакетами также очень просто и носит название pacman (от packages manager, нужно полагать). Формат её вызова таков:

$ pacman <действие> [опции] имя_файла_пакета

Указание действия является обязательным, опций, в соответствие с названием - опциональным.

Действия, предусмотренные командой pacman, следующие:

  • -A, или --add - добавление (то есть установка) пакета в систему;
  • -U, --upgrade, и -F, --freshen, - обновление пакета; различие между ними в том, что во втором случае обновляется только ранее инсталлированный (посредством -A) пакет, в первом же - установка осуществляется и при отсутствии оного;
  • -S, --sync, - синхронизация локально установленных пакетов с репозиторием дистрибутива (ftp.archlinux.org) или его зеркалами;
  • -R, --remove, - удаление пакета, выполняемое без всяких предупреждений, вместе со всеми его конфигурационными файлами и прочим хозяйством (за исключением, разумеется, пользовательских конфигов из каталога $HOME);
  • -Q, --query, - запрос информации о пакете, установленном или не установленном;
  • -V, --version, - вывод номера версии pacman, сведений о копирайте и лицензии.

В качестве аргументов команды pacman при действиях -A, -U и -F должны выступать полные имена файлов пакетов, вида - pkg_name-version-release.pkg.tar.gz. Если пакет расположен в одном из предназначенных к тому мест (о них я скажу чуть позже), то достаточно приведённой формы, в противном случае потребуется указание полного пути. В одной строке можно перечислить несколько пакетов для единовременной установки или обновления. Действия -Q, -S и -R требуют только указания имени пакета, без прочей атрибутики.

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

$ pacman -hA

даст список всех опций, которые доступны при действии --added:

usage:  pacman {-A --add} [options] <file>
options:
  -d, --nodeps        отменить проверку зависимостей
  -f, --force         принудительная установка
  -v, --verbose       включение вывода сообщений о
  ходе операции
  -r, --root <path>   установка корня
  пакета, отличного от "умолчального" /

Опции команды pacman довольно многочисленны, что компенсируется их обычной необязательностью. Важными могут быть -d, --nodeps, отменяющая проверку зависимостей, и -f, --force, - принудительная установка пакета, а также -r, --root, предписывающая отличный от умолчального исходный каталог (а им является корень файловой системы) и требующий, естественно, указания пути (например, /usr/local или /opt. Отмечу ещё опцию -c, --cascade, так как применение её требует особой осторожности: она предписывает рекурсивное удаление не только указанного пакета, но и всех, связанных с ним зависимостями. Обратим внимание, что опции, в отличие от действий, в краткой форме даются исключительно в нижнем регистре.

Наконец, самая интересная опция - -u, --sysupgrade. Используемая вместе в действиями -U или, ещё лучше, -S, она обеспечивает тотальное обновление всей системы (точнее, только тех её компонентов, которые установлены из official-пакетов):

$ pacman -Su

Очевидно, что во втором случае требуется подключение к Сети для синхронизации с репозиториями Archlinux. Если же скачать все обновлённые официальные пакеты заблаговременно, можно обойтись без этого:

$ pacman -Uu

Для ознакомления с прочими опциями предлагается обратиться к тёте Мане - man pacman.

Настройка pacman

Выше я вскользь обмолвился, что для упрощения установки пакетов их следует разместить в должном месте. А место это определяется в файле конфигурации pacman - /etc/pacman.conf.

Как и все а Archlinux, файл этот устроен очень просто и состоит из двух секций - общих настроек установки пакетов и списка репозиториев оных. К общим настройкам относятся:

IgnorePkg = pkg1 pkg2 ...

которой определяется список пакетов, не затрагиваемых при тотальном обновлении посредством pacman -Su;

NoUpgrade = etc/passwd etc/group etc/shadow...

содержащая список файлов, которые не должны перезаписываться ни при каких установках и обновлениях пакетов (в том числе и при тотальном апдейте); по умолчанию здесь, кроме указанных, перечислены все основные общесистемные конфиги типа etc/fstab, etc/rc.conf, etc/rc.local, и т.д.;

DBPath = /path/to/db/dir

путь к базе данных пакетов (по умолчанию - /var/lib/pacman);

NoPassiveFtp

отключение пассивного режима ftp-соединения (по умолчанию используется именно он - и это, товарищи, правильно в большинстве случае).

В списке репозиториев Arch'а указан главный ftp-сервер проекта

Server = ftp://ftp.archlinux.org/current

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

Server = local:///home/arch/pkg

Именно нахождение пакета в одном из репозиториев, перечисленных в файле /etc/pacman.conf, избавляет от необходимости указывать полный путь к файлу пакета, о чем говорилось ранее. Понятно, что установка пакета с ftp-сервера требует подключения к Сети. Локальный же репозиторий, куда можно разместить пакеты, скачанные заблаговременно, избавляет от этой необходимости.

Pacman - проблема зависимостей

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

Тем не менее контроль зависимостей в системе управления пакетам Archlinux существует. Эта функция возложена на внешнюю (по отношению к каждому пакету) базу данных, расположенную в каталоге /var/lib/pacman/. Она включает в себя два подкаталога - /var/lib/pacman/current/ и /var/lib/pacman/local. В первом - база всех пакетов, охваченных дистрибутивом Arch Linux (вернее, официальной его частью). Она образована каталогами вида pkg-ver-rel (например, bash-2.05b-6 - приводимые ниже примеры относятся к этому пакету), в каждом из которых имеется по два файла: desc - краткое описание пакета в форме

%NAME%
bash

%VERSION%
2.05b-6

%DESC%
The GNU Bourne Again shell

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

%DEPENDS%
glibc
grep
readline
ncurses

%CONFLICTS%

В каталоге /var/lib/pacman/local/, как следует из его названия, содержится база пакетов, установленных на данной машине. Он образован точно также, как и /var/lib/pacman/current/, однако в каталоге каждого пакета - уже по три файла: desc, depends и files.

Описание пакета в файле desc включает, помимо краткой информации (аналогичной описанию из current), также даты построения и установки пакета, имя сборщика (для официальной части им выступает обобщённый archlinux), и суммарный размер:

%NAME%
bash

%VERSION%
2.05b-6

%DESC%
The GNU Bourne Again shell

%URL%


%BUILDDATE%
Mon Jan 06 22:49:26 2003

%INSTALLDATE%
Wed Oct 22 08:14:09 2003

%PACKAGER%
Arch Linux (http://www.archlinux.org)

%SIZE%
1318400

В файле depends, кроме списка пакетов, от которых зависит данный, приведён и список пакетов, которые зависят от него:

%DEPENDS%
glibc
grep
readline
ncurses

%REQUIREDBY%
m4
diffutils
autoconf
automake
...

Наконец, files - это просто список всех компонентов пакета с указанием путей, по которым они размещаются при инсталляции:

%FILES%
bin/
bin/sh
bin/bash
etc/
etc/profile
usr/
usr/man/
usr/man/man1/
usr/man/man1/bash.1

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

%BACKUP%
etc/profile	db618b683dee3f98f72bbb666ab0963c

Эта информация понадобится при удалении пакета командой pacman -R - для восстановления первозданной конфигурации системы (именно благодаря ей pacman способен к "чистой" деинсталляции пакетов).

Из структуры базы пакетов легко понять принцип контроля зависимостей в Archlinux: при установке нового пакета программа pacman сначала проверяет каталог /var/lib/pacman/current/ на предмет выявления его зависимостей, а потом - каталог /var/lib/pacman/local/ на предмет того, установлены ли пакеты, от которых зависит данный. Если все в порядке - пакет успешной устанавливается. Если же нет - выдаётся список имён недостающих пакетов (в порядке, котором они должны инсталлироваться) и работа pacman'а завершается сообщением об ошибке. Никаких попыток разрешить нарушение зависимостей автоматически он не делает, оставляя это на долю пользователя.

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

Такая система может показаться не очень удобной. Хотя это гораздо лучше, чем классический rpm, где при нарушении зависимостей выдаётся что-нибудь типа недостачи библиотеки имя_рек.so.1 - и давай вычисляй, в состав какого пакета она входит. В Archlinux же вывод команды pacman выглядит примерно следующим образом:

pacman -A gnome-desktop-2.4.0-1.pkg.tar.gz           11:01 pts/2
error: unsatisfied dependencies:
gnome-desktop: requires libgnome
gnome-desktop: requires gnome-vfs

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

Руки против автоматики - плюсы и минусы

Тем не менее, в сравнении с такими как-бы "продвинутыми" системами управления пакетами, как apt или даже yum, pacman выглядит весьма примитивно. Однако это а) не так (потому что он не более чем дополнение к ABS), и б) имеет свои преимущества.

Об ABS речь впереди, а вот о преимуществах "ручного" подхода pacman (в CRUX принята примерно такая же система, да и pkg-tools из Slackware не сильно от них отличается) перед системами типа apt я хотел бы поговорить подробнее ввиду их не полной очевидности.

Что происходит, когда мы прибегаем к услугам apt или yum? Система пакетного менеджмента определяет, что для установки данного пакета не хватает таких-то компонентов, связанных с ним зависимостями, отыскивает их (на локальном носителе или в Сети), скачивает, устанавливает (вместе со всеми уже их зависимостями), после чего благополучно инсталлирует запрошенный пакет. Красота, да и только - "и не думать ничего, фюрер мыслит за него" (пардон, майнтайнер, разумеется).

Однако вспомним, что зависимости пакетов бывают двух родов: обязательные, или жесткие, и не обязательные, так сказать, "мягкие". Первые - объективная реальность, определяющая непременность их исполнения: никакую программу невозможно заставить работать без glibc (о статической линковке здесь не говорим), никакое X-приложение не будет функционировать без xlib, ни одна KDE-софтина не встанет без Qt и kdelibs.

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

Так вот, в Archlinux пользователь, получив предупреждение о том, что нужный ему пакет требует того-то и того-то, при минимальном опыте (и некотором представлении о зависимостях) может определить, относятся ли навязываемые ему зависимости к числу "жестких", объективных, или "мягких", обусловленных субъективными представлениями сборщика пакета. И во втором случае - осознанно сделать выбор:

  • простоты ради согласиться со сделанным ему предложением (что, правда, приведет к захламлению системы),
  • отказаться от удовлетворения зависимостей посредством опции nodeps (в этом случае есть некоторый риск того, что пакет не будет функционировать должным образом - впрочем, для "мягких" зависимостей риск этот не слишком велик),
  • или просто плюнуть и собрать требуемый пакет из исходников вручную - только с теми with/without и enable/disable, которые ему действительно нужны.

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

Впрочем, если рассматривать Archlinux как фундамент для построения собственной системы, ограничившись только компонентами base и все остальное собирая вручную - такой путь вполне приемлем. Если все же ориентироваться на смешанное его использование - критически важные компоненты собираются вручную, все остальные - устанавливаются из прекомпилированных пакетов, - то выход все равно остается. Поскольку база данных, используемая pacman'ом, очень проста, никто не запрещает внести в нее сведения о "самосборном" пакете вручную (правда, здесь нет такого средства автоматизации этого процесса, как inject в Gentoo).

Однако у пользователя Arch'а есть и еще одна, более интересная, возможность. И это - использование ABS (Arch Build System), системы построения пакетов, которая составит тему следующей заметки.

ABS - система построения пакетов

Вот я наконец и добрался до самого интересного, что есть в Archlinux - до системы построения пакетов Arch Build System (сокращенно ABS). Это развитие концепции портов CRUX, которые, в свою очередь, являют собой прямое продолжение системы портов FreeBSD. Подобно последней, ABS - автоматизированная система построения и установки пакетов из исходных текстов, обладающая, однако, рядом особенностей.

Основное назначение порта FreeBSD (и идеологически сходным с ними портежей Gentoo) - инкорпорация собранного пакета в дерево текущей файловой системы. Конечно, посредством системы портов можно также собрать и бинарный пакет, предназначенный для автономного распространения - более того, все содержимое коллекции packages именно так и собирается, однако это требует небольшого дополнительного телодвижения.

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

ABS же в равной мере приспособлен и к тому, и к другому. Хотя, в отличие от FreeBSD, автономный пакет создается в любом случае. Впрочем, по порядку.

Получение ABS

Порядок же в Archlinux таков, что для того, чтобы начать работать с ABS, ее следует получить. В отличие от портов FreeBSD или портежей Gentoo, приобрести дерево ABS в виде единого тарбалла не удастся (впрочем, в CRUX с некоторого времени ежедневный тарбалл дерева портов также стал недоступен). Соответственно, поиметь дерево ABS наиболее простым способом можно из уже установленной системы Archlinux. В принципе, получить к нему доступ можно и другими способами, например, через интерфейс cvsweb, или через cvs просто, но это показалось мне менее удобным (или более сложным).

А под Archlinux - все просто: достаточно дать (от лица суперпользователя) команду abs (это простой bash-скрипт в каталоге /usr/bin). Которая и выполнит (при наличии подключения к Сети любого рода) соединение с сервером Archlinux и скачает с него актуальное (обновляемое ежедневно) ABS-дерево. Суммарный объем которого (в несжатом состоянии) чуть больше 3 Мбайт, то есть посилен даже для модема. В результате в файловой системе волшебным образом появится каталог /usr/abs, включающий всю систему построения пакетов. А далее ABS-дерево потребует только периодического обновления - процедуры, при мало-мальски нормальной телефонной линии занимающей считанные минуты даже по модему...

Что именно скачивается по команде abs - определяется конфигурационными файлами из /etc/abs. Полное дерево ABS включает в себя все пакеты Arch Linux, как официальные (official - это те, что имеются на полном CD), за получение которых отвечает файл /etc/abs/supfile, так и неофициальные (unofficial или contrib) и нестабильные (unstable), что определяется файлами /etc/abs/supfile.unofficial и /etc/abs/supfile.unstable, соответственно. Если пакеты unofficial (contrib) и unstable не нужны, для предотвращения скачивания их портов нужно просто стереть соответствующие файлы.

Порты официальных пакетов по умолчанию берутся из дерева current. При желании иметь только порты стабильной версии, следует отредактировать файл /etc/abs/supfile, заменив строку

*default tag=CURRENT

на

*default tag=STABLE

Конечно, для построения пакетов из исходников потребуются еще и сами исходники. Как и во всех системах портирования, в ABS предусмотрен механизм их автоматического получения из Сети (как правило, с мастер-сайтов разработчиков) по потребности. Однако тут счет пойдет уже не на мегабайты. И потому в домашне-модемных условиях исходники желательно скачивать заблаговременно (например, по служебной выделенке). И размещать в специально предназначенном для них месте - забегая вперед, скажу, что по умолчанию таковым выступает каталог /var/cache/pacman/src.

Правда, простого способа автоматически получить список тарбаллов, необходимых для установки данного пакета в Archlinux (в отличие от FreeBSD или Gentoo) не предусмотрено. Тем не менее, выкопать все потребное (с учетом зависимостей) можно: только для этого придется залезть во внутренности ABS'а. Это мы сделаем несколько позже, а пока посмотрим на

ABS снаружи

Первое, что можно (и нужно) сделать по получении дерева ABS - это ознакомиться с его устройством. Как уже было сказано, произрастает оно из каталога /usr/abs, включающего подкаталоги, соответствующие группам пакетов (тем самым, которые мы видели при установке Archlinux в меню setup, если выполняли ее с полного диска):

$ ls /usr/abs
base/	editors/	kde/	local/	office/
unofficial/	xfce4/
daemons/	gnome/	kernels/	multimedia/
PKGBUILD.proto	unstable/
devel/	install.proto	lib/	network/
system/	x11/

Кроме того, в корне /usr/abs можно видеть два файла - PKGBUILD.proto и install.proto. Это - прототипы скриптов для разработки собственных abs-портов, о чем мы поговорим под занавес.

В каждом из подкаталогов /usr/abs можно видеть каталоги следующего уровня вложенности, соответствующие отдельным пакетам. А в них уже - минимум по одному файлу, всегда именуемому PKGBUILD. Это и есть собственно сценарий построения пакета, аналог make-файлов из портов FreeBSD и ebuild'ов из портежей Gentoo.

В каталогах некоторых пакетов можно обнаружить и другие файлы. Ими могут быть прототипы конфигов или патчи, необходимые для успешной сборки пакетов и адаптации их к Arch-окружению. Подобно портам FreeBSD, все дистрибутив-специфичные патчи интегрированы непосредственно в дерево ABS, а не скачиваются из общего репозитория с исходниками, как в портежах Gentoo. Прочем, на сервере Archlinux такого общего репозитория и нет - все исходники берутся или с мастер-сайтов разработчиков, или, реже, с крупных ftp-архивов типа www.sourceforge.net.

Как работает ABS

А работает ABS, как и все в Archlinux, до безобразия просто. Для построения пакета в общем случае достаточно перейти в каталог нужной программы (например, /usr/abs/base/bash) и дать команду

$ makepkg

без всяких опций и аргументов. По этой команде выполняются следующие действия:

  • проверка каталога /var/cache/pacman/src на наличие исходников пакета и, при отсутствии таковых, их скачивание;
  • проверка базы данных установленных пакетов на предмет зависимостей; в случае их удовлетворения процедура продолжается, иначе выдается сообщение об ошибке;
  • копирование тарбалла исходников в каталог /usr/abs/category/pkg_name/src, распаковка его там же (в результате чего образуется подкаталог ~/src.pkg_name) и, при необходимости, наложение соответствующих патчей;
  • переход в корень дерева исходников пакета и запуск сценария ./configure --prefix=/usr (и, возможно, другими опциями конфигурирования);
  • запуск make на предмет сборки пакета;
  • промежуточная инсталляция скомпилированных компонентов в подкаталоги каталога /usr/abs/category/pkg_name/pkg (~/bin, ~/etc и т.д.);
  • удаление из дерева собранного пакета "ненужных" подкаталогов (например, с info- и html-документацией);
  • очистка сгенерированного кода от отладочной информации;
  • архивирование и компрессия компонентов пакета (из каталога ~/pkg) в единый тарбалл.

Если все стадии процесса завершились успешно, то в результате в каталоге /usr/abs/category/pkg_name/ появится файл pkg_name.pkg.tar.gz, который и представляет собой скомпилированный пакет, могущий быть установленным обычным образом - командой pacman -A, или использован для обновления уже установленного пакета путем pacman -U (что, впрочем, не является единственным способом инсталляции, как будет показано чуть ниже).

В процедуре построения пакета обращает на себя внимание то, что проверка зависимостей производится фактически дважды. Первый раз - при сверке базы установленных пакетов (из /var/lib/pacman/) со списком зависимостей приведенных в build-файле (а, забегая вперед, замечу, что в нем описываются отнюдь не все зависимости пакета). Если на этой стадии проверка не проходит, по умолчанию, как уже было сказано, просто выдается сообщение об ошибке без попытки разрешения ситуации. Однако с этим можно бороться: опция -b, она же --builddeps, именно и предназначена для построения пакетов, от которых зависит данный, в ходе его сборки.

Второй раз зависимости проверяются уже в реальности, при исполнении скрипта ./configure. И здесь можно ожидать, что нарушение зависимостей приведет просто к прекращению сборки. Я с таким пока не сталкивался, но, теоретически рассуждая, исключить вероятность такой ситуации, учитывая характер описания зависимостей в build-файле (о чем - ниже) нельзя.

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

По умолчанию ABS не устанавливает собранный пакет, требуя для этого привлечения pacman. Однако если команда makepkg дана с опцией -i, --install, то успешное завершение сборки пакета повлечет за собой и его инсталляцию. При этом и сборка, и установка проводятся в один прием. Если же дать команду

$ makepkg -i

в отношении уже построенного пакета, последует сообщение об ошибке. Избежать этого можно, присоединив еще и опцию -f, --force:

$ makepkg -if

В этом случае существующий пакет будет принудительно пересобран и, вслед за тем, установлен.

Легко видеть, что в процессе построения пакета задействуется большой объем дискового пространства: под тарбалл исходников в /var/cache/pacman/src, его дубликат в дереве /usr/abs, под развернутое дерево исходников со всеми промежуточными продуктами компиляции, под дерево собранных бинарников в подкаталоге пакета, и, наконец, под тарбалл окончательно собранного пакета. Причем в полезном остатке окажется только последний, да и то только в том случае, если он сразу же не будет установлен в файловой системе. Все остальное же следует отнести к непроизводительным тратам дискового пространства - по крайней мере, для большинства пользователей, не отягощенных необходимостью отлаживать собственные abs-порты.

Возникает резонный вопрос - а есть ли способ борьбы с таким расточительством, помимо ручного вычищения дерева /usr/abs?

Разумеется, есть - последует столь же резонный ответ. Это - опция -c, --clean, которая очищает дерево /usr/abs от всех промежуточных продуктов жизнедеятельности, оставляя только тарбалл собранного пакета *.pkg.tar.gz.

Есть и более жесткая опция -C, --cleancache, которая заодно вычищает и исходный тарбалл из /var/cache/pacman/src. Чего, впрочем, я не стал бы делать без крайнейшей необходимости - никогда не следует зарекаться от того, что возникнет необходимость пересобрать уже собранный пакет.

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

$ makepkg -ifc

для установки построенного пакета, вне зависимости от того, имела ли место предыдущая сборка, или нет, с последующей очисткой дерева /usr/abs и сохранением исходного тарбалла в /var/cache/pacman/src.

У команды makepkg есть еще несколько опций, одна из которых нам скоро понадобится. Это - -p имя_файла, предписывающая использовать в качестве build-сценария не штатный PKGBUILD пакета, а некий файл с произвольным именем.

ABS изнутри

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

"Заголовочная" часть build-пакета представляет собой комментарий, содержащий краткие сведения о построении пакета, имя сборщика и разместителя:

# $Id: PKGBUILD,v 1.17 2003/11/06 08:26:12 dorphell Exp $
# Maintainer: judd <jvinet@zeroflux.org>
# Committer: Judd Vinet <jvinet@zeroflux.org>

Далее идут имя пакета, номер версии и номер сборки. Первые два - авторские, номер же сборки дается в рамках системы ABS.

pkgname=bash
pkgver=2.05b
pkgrel=8

Затем следует краткое описание пакета, адрес сайта разработчика (не ftp-сервера, откуда он скачивается), опциональная строка с именем конфига, подлежащего сохранению в целевой системе, и описание зависимостей:

pkgdesc="The GNU Bourne Again shell"
url="http://www.gnu.org/software/bash/bash.html"
backup=(etc/profile)
depends=('glibc' 'readline')

Если сравнить описание зависимостей build-файла с таковым из файла depends базы данных пакетов (/var/lib/pacman/), можно увидеть, что в первом случае они ни в коей мере не охватывают всех пакетов, от которых зависит данный. Насколько я смог понять, в build-файле включаются а) самые важные из "жестких" зависимости (в приведенном примере - glibc), б) опциональные зависимости из числа "мягких", которые разработчики сочли необходимым включить (в приведенном примере - readline), и в) зависимости от пакетов, которые могут быть альтернативно заменимыми (так, для текстового редактора nedit здесь можно видеть зависимость от lesstif, альтернативой чему мог бы выступить OpenMotif - я понятно выразился?). Именно поэтому, как я уже говорил, нельзя исключить ситуации, когда при реальном конфигурировании исходника будет обнаружена недостача какого-либо компонента из числа "жестких" или умолчальных "мягких" зависимостей.

В следующей строке build-файла указывается URL сервера, с которого следует брать исходник программы, если его не окажется в /var/cache/pacman/src:

source=(ftp://ftp.ibiblio.org/pub/gnu/\
$pkgname/$pkgname-$pkgver.tar.gz profile)

Именно его следует использовать, подставив вместо переменных $pkgname и $pkgver их значения, для предварительного скачивания исходников при отсутствии прямого подключения машины (или плохом коннекте с нее). Правда, придется еще пройтись по build-файлам пакетов, от которых зависит устанавливаемый, для извлечения адресов для их скачивания. Способа автоматизации этой процедуры я не обнаружил. Хотя принципиальных препятствий к написанию соответствующего скрипта также не просматривается.

В приведенном примере в строке source мы видим еще одни компонент - файл profile без указания адреса. Это значит, что он берется непосредственно из каталога пакета в дереве /usr/abs. И действительно, если просмотреть содержимое его для пакета bash, можно увидеть там файл с этим именем - прототип общесистемного /etc/profile. А в пакетах, которые для установки в Arch должны быть пропатчены, в строке source обнаружится имя патча, а одноименный файл будет присутствовать в каталоге пакета.

Наконец, далее идет собственно описание процесса сборки пакета и его последующей обработки. В общем случае оно включает в себя следующие директивы:

  1. переход в каталог развернутого дерева исходников:
  2. 	cd $startdir/src/$pkgname-$pkgver
    	
  3. выполнение конфигурационного сценария с опцией, предполагающей (для большинства пакетов) последующую установку в каталог /usr:
  4. 	./configure --prefix=/usr
    	
  5. собственно компиляцию и линковку:
  6. 	make
    	

    и, наконец, собранных компонентов пакета в промежуточный каталог:

    	make prefix=$startdir/pkg/usr install
    	

Дополнительно могут присутствовать строки, предписывающие истребление лишней документации (info и html), удаление отладочной информации, создание необходимых ссылок - в случае с bash это будет

ln -sf $pkgname sh

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

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

Индивидуализируем ABS

Индивидуализация ABS включает в себя два аспекта - глобальную настройку системы построения пакетов и локальное редактирование build-сценария конкретного пакета.

Глобальные настройки условий сборки описываются в файле /etc/makepkg.conf. Она сводится к определению серии переменных окружения, влияющих на получение исходников, и условий компиляции.

В первой, после комментариев, строке /etc/makepkg.conf определяется корневой каталог для всей ABS, по умолчанию:

export ABSROOT="/usr/abs"

Что менять не вижу ни малейшего резона.

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

export FTPAGENT="/usr/bin/wget --continue \
	--passive-ftp --tries=3 --waitretry=3"

Меня лично wget более чем устраивает (единственно, в условиях нашего не лучшего коннекта я подретушировал бы ретрайвы), но желающие могут выбрать что-то из приведенного ниже

#export FTPAGENT="/usr/bin/snarf"
#export FTPAGENT="/usr/bin/lftpget -c"

или любой иной наличный ftp-клиент.

Далее идут закомментированные примеры флагов оптимизации для gcc, отличные от умолчальных:

# Pentium Pro/Pentium II/Pentium III+/Pentium 4/Athlon optimized (but
binaries
# will run on any x86 system)
#export CHOST="i686-pc-linux-gnu"
#export CFLAGS="-mcpu=i686 -O2 -pipe"
#export CXXFLAGS="-mcpu=i686 -O2 -pipe"

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

Опций для SMP-систем касаться не будем - это пока не актуально для подавляющего большинства пользователей. А вот последней строкой можно прославить свое имя в веках (по крайней мере, среди пользователей своей локальной машины - скорее всего, себя же, любимого), указав его в качестве значения переменной PACKAGER, и сопроводив своим e-mail'ом:

export PACKAGER="Имя рек <imya_rek@domain.ru>"

На этом глобальные настройки в первом приближении заканчиваются. Переходим к конкретным пакетам. И вот здесь самое время вспомнить об опции -p file_name. Каковая позволяет нам, дабы не курочить штатный build-файл, скопировать его

$ cp BUILDPKG MYBUILD

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

$ makepkg -p MYBUILD

В каком направлении редактировать? Если вспомнить строение build-файла, ясно, что ближайшим кандидатом является строка ./configure. Здесь с помощью опций with/without и enable/disable можно прибавить данному пакету функциональности или, напротив, отнять оной. Правда, для этого хорошо бы знать, какие значения этих опций предусмотрел автор. Но тут я вам не помощник - единственный к тому способ, известный мне, заключается в предварительной распаковке исходного тарбалла и запуске скрипта

$ ./configure --help

Далее, можно изменить значение опции --prefix в соответствие со своими привычками, заменив умолчальное для большинства пакетов /usr на, скажем, /opt. Впрочем, это имеет смысл делать только для больших "самодостаточных" пакетных комплексов типа KDE, а они и так в Archlinux по умолчанию устанавливаются в /opt.

А вот для любимой командной оболочки (если ею является не bash) есть смысл добавить еще опцию --bindir=/bin: завсегда полезно, чтобы главный рабочий инструмент POSIX'ивиста находился под рукой (сиречь непосредственно в корневой файловой системе - ведь и /usr, и /opt вполне могут лежать на отдельных разделах).

Наконец, здесь же (или в строке make) можно задать флаги компиляции, отличающиеся от умолчальных (определенных, напомню, в файле /etc/makepkg.conf) - более жесткие при критичности быстродействия или, напротив, смягченные для пакетов, отказывающихся собираться при высоких уровнях оптимизации.

Как это ни парадоксально, но подкорректировать можно и строку описания зависимостей. Указав здесь, скажем, возможный альтернативный пакет (как в приведенном выше примере для nedit). Или, напротив, исключив зависимость заведомо необязательную. Так, в строке depends build-файла для редактора joe я с удивлением обнаружил gpm - сколько раз я ни собирал свой любимый редактор, а ни малейшей потребности в этом самом gpm'е не наблюдал...

В общем, простор для индивидуальной модернизации build-файла любимого и хорошо известного пакета весьма широк. Можно даже сделать build-файл для построения пакета более свежей, нежели наличная, версии - для этого потребуется только подкорректировать строки pkgver и pkgrel. Впрочем, здесь мы уже вплотную подходим к вопросу создания собственных abs-портов, а это увлекательное занятие описываетося в следующем разделе.

А дабы окончательно заинтриговать читателя, замечу наперед, что, кроме команды построения пакета - makepkg, в Arch'е есть и команда переустройства мира - makeworld, аналог известных средств make world из FreeBSD или emerge world из Gentoo.

Предварительные итоги

А пока подведем предварительный итог нашего рассмотрения систем управления пакетами и их построения в сравнении с аналогами - портами FreeBSD, портами CRUX и портежами Gentoo.

С первого же взгляда бросается в глаза, то ABS Archlinux'а далеко уступает в универсальности Gentoo'шным портежам. Если в последних все зависимости можно отрегулировать раз и навсегда, варьируя значения переменной USE (что не исключает их индивидуального переопределения при необходимости), то здесь для этого требуется ручная правка build-файла.

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

В сравнении с портами FreeBSD abs'ы от Archlinux (да простят мне читатели этот неологизм) выглядят менее гибкими в использовании. Так, если выполнение полного цикла установки порта во FreeBSD можно ограничить на любой стадии - только скачать исходник, скачать и распаковать, скачать, распаковать и собрать без инсталляции, и т.д. - то в ABS предусмотрено, в сущности, только два target'а - построение пакета и его построение с установкой. Причем даже во втором случае в качестве отхода жизнедеятельности остается собранный бинарный пакет (а при сборке с одновременной инсталляцией он, скорее всего, будет именно отходом).

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

При сравнении же ABS с портами CRUX в первую голову проступает их кровное родство, обусловившее фенотипическое сходство. И тем не менее, различие есть - опять же в простоте, теперь уже - только использования. Особенно наглядное при сравнении не собственно портов того и другого дистрибутива, а их систем пакетного менеджмента (внимательный читатель наверняка понял: во всех поминаемых здесь системах, от FreeBSD до Archlinux, пакетный менеджмент есть лишь частное проявление механизма портирования). Если в CRUX каждое действие в отношении пакета (установка, удаление, получение информации, и т.д.) требует своей отдельной команды, то Arch во всех случаях обходится одной - pacman, причем с очень логично разделенными опциями первого порядка (то есть действиями) и собственно опциями.

В общем, выражаю свое скромное личное мнение: система обращения с пакетами дистрибутива Arch (не будем разрывать pacman и ABS) - а) одна из самых простых в использовании, какие я видел, б) очень логично построенная, и в силу этого, в) легко индивидуализируемая. А не к тому ли стремится множество пользователей, которых, с одной стороны, не устраивают жесткие рамки пакетной дистрибуции, а, с другой - не нуждающихся во всеохватности и универсализме?

Строим свой ABS-порт

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

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

В любом случае, идет ли речь об обновлении порта или создании его с нуля, процесс не сложен. И подробно описан в официальной документации. В abs-дереве предусмотрен даже специальный каталог для собственного творчества - /usr/abs/local. Отправляемся туда и создаем подкаталог, имя которого должно совпадать с авторским наименованием портируемого пакета (без указания версии). Далее туда из корня abs-дерева копируем прототип build-файла (без указания префикса):

$ cp /usr/abs/PKGBUILD.proto /usr/abs/local/pkg_name/PKGBUILD

И спокойно приступаем к его потрошению. Устроен build-прототип следующим образом:

pkgname=NAME
pkgver=VERSION
pkgrel=1
pkgdesc=""
url=""
depends=()
conflicts=()
backup=()
install=
source=($pkgname-$pkgver.tar.gz)
md5sums=()

build() {
  cd $startdir/src/$pkgname-$pkgver
  ./configure --prefix=/usr
  make || return 1
  make prefix=$startdir/pkg/usr install
}

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

В четвертой строке задается URL домашней страницы проекта, типа http://www.имя_рек.org. Если, как это иногда бывает, единственный адрес для пакета - это ftp-сервер, с которого его качают, эту строку можно оставить пустой.

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

depends=('glibc' 'ncurses')

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

Увлекаться перечислением зависимостей, насколько я понимаю, не следует. Достаточно указать пакеты а) критически важные для установки, б) те, которые обеспечивают необходимые дополнительные опции (например, gpm - для консольных приложений, оный поддерживающих) и в) пакеты, для которых возможен альтернативный выбор (например, lesstif или OpenMofit).

Строка conflicts=(), как явствует из названия, по смыслу противоположна предыдущей: в ней следует перечислить (по тем же правилам) пакеты, с которыми конфликтует устанавливаемый. Впрочем, возможно, что таковых не имеется - в этом случае строку просто опускаем.

Также необязательны и две следующие строки. В строке backup перечисляются файлы, для которых следует сохранить наличные в файловой системе версии. Обычно это касается конфигурационных файлов из каталога /etc и его аналогов. А строка install указывает, при необходимости, на имя установочного скрипта, который должен вызываться после построения пакета для завершения его инсталляции, например, для Иксов она имеет вид:

install=xfree86.install

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

source=(ftp://ftp/path/$pkgname-$pkgver.tar.gz)

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

source=(ftp://ftp/path/$pkgname-$pkgver.tar.gz patch1.patch ...)

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

Описание это стандартно, начинаясь с перехода в каталог с распакованными исходниками

cd $startdir/src/$pkgname-$pkgver

за которым следуют три сакраментальные команды

$ ./configure
$ make
$ make install

Здесь важны:

  • указание префикса конфигурирования - --prefix=/usr, так как по умолчанию пакеты из исходников обычно устанавливаются в /usr/local, где система контроля зависимостей Arch'а может их потом и не найти (во всяком случае в отношении библиотек этого правила лучше придерживаться неукоснительно);
  • указание кода возврата return 1, предписывающего начать промежуточную установку пакета только после успешного завершения его сборки (что, в принципе, очевидно);
  • указание префикса для промежуточной инсталляции собранных бинарников - prefix=$startdir/pkg/usr: без этого makepkg не сможет собрать их в бинарный тарбалл (который сам временно помещается непосредственно в каталог $startdir.

Закончив редактирование build-файла и озаботившись выходом в Сеть (или разместив предварительно скачанные исходники в /var/cache/pacman/src), можно запустить пробную сборку пакета:

$ makepkg

Это безопасно - без указания опций будут выполнены: а) распаковка исходников в каталог $startdir/src, б) его конфигурирование и сборка, в) промежуточная инсталляция в подкаталоги $startdir/pkg/usr/{bin,etc,share...}, и г) сборка и компрессия бинарного тарбалла в $startdir. Сам пакет установлен не будет. Зато все промежуточные отходы жизнедеятельности при этом сохраняются - они могут понадобиться при неудачной сборке для разбора полетов.

Потому что гарантировать безошибочность сборки с первого раза я бы не стал, вполне возможно появление сообщений об ошибках различного рода. В этом случае следует проанализировать а) сообщения об ошибках, и б) make-файлы из дерева исходников (не зря же мы их сохранили в каталоге $startdir/src/$pkgname-$pkgver при пробной сборке). Часто причина ошибок очень тривиальна - например, в make-файле жестко прописаны какие-либо важные пути, и они не соответствуют таковым в файловой системе Archlinux.

Решается эта проблема просто: первозданное дерево исходников копируется

$ cp pkgname-pkgver pkgname-pkgver-orig

Затем в нужный файл (или файлы) первого каталога вносятся необходимые коррективы, после чего командой diff создается patch-файл, например, вот так:

diff -Naur pkgname-pkgver-orig/Makefile \
pkgname-pkgver/Makefile > pkgname.patch

Каковой и следует поместить в корень порта, наравне с build-файлом. А в последний - внести изменения: дополнить строку source именем патча, а в описании сборки строку ./configure предварить командой наложения патча, типа:

patch -Np1 -i ../pkgname.patch

И еще: система управления пакетами Archlinux весьма сурова по отношению ко всякого рода балласту, безжалостно вычищая из дерева промежуточной инсталляции (каталога $startdir/pkg/usr/) всякого рода подкаталоги с дополнительной (по отношению к man-страницам) документацией типа doc. Само по себе это можно приветствовать, однако в ряде случаев ведет к потерям примеров конфигурационных файлов (разработчики подчас помещают их вместе с документами).

Однако это легко обходимо: все нужные конфиги (причем предварительно доведенные под собственные задачи) также помещаются в корень каталога $startdir, имена их прописываются в строке source (разумеется, без указания URL - ведь они будут браться с локального хранилища), а в конец директивной части build-файла добавляется несколько строк, определяющих, где эти конфиги должны быть размещены, например:

mkdir -p $startdir/pkg/etc
cp ../profile $startdir/pkg/etc

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

$ pacman -A (или -U) pkgname-pkgver.pkg.tar.gz

Или, что предпочтительней, еще раз пересобрать его с одновременной инсталляцией:

$ makepkg -if

Обратим внимание на опцию -f - поскольку файл бинарного тарбалла (пусть и ошибочно собранного) в наличии имеется, без нее повторить процедуру сборки не удастся.

Почему второй способ предпочтительней? Использование команды makepkg без опций быстро приводит к захламлению abs-дерева промежуточными продуктами компиляции - скопированными тарбаллами исходников, каталогами с результатами их развертывания, деревом промежуточной инсталляции бинарников. Каковые при успешной сборке больше никогда не понадобятся. А вот результаты работы - бинарные тарбаллы, - очень даже могут пригодиться. И выуживать их потом из развесистой кроны ABS-дерева - не самое лучшее занятие.

Обе эти проблемы решаются парой дополнительных опций: -c, предписывающей очистить abs-дерево от отходов производства (каталогов $startdir/src и $startdir/pkg), и -w /path, благодаря которой итоговые бинарные тарбаллы будут сконцентрированы в некоем специально предназначенном для них каталоге (например, $HOME/mypkg). В результате финальная команда для нашего порта приобретет такой вид:

$ makepkg -ifc -w $HOME/mypkg

Причем в отношении последнего действия жизнь можно сделать еще проще. Я, например, определил такой псевдоним для makepkg:

alias makepkg='makepkg -w $HOME/mypkg'

и занес его в профильный файл root'а (у меня это /root/.zshrc): излишне напоминать, что хотя вся работа по созданию и тестированию порта может выполняться обычным пользователем, для итоговой установки (вне зависимости, через pacman или через makepkg) потребуются привилегии администратора.

Вот, собственно, и все. Не знаю, насколько мне удалось отразить в своем описании простоту подготовки собственного abs-порта. Если нет - уверяю вас, достаточно внимательно ознакомиться с несколькими build-файлами и чуть-чуть потренироваться самому - и все станет кристально ясно.

[ опубликовано 03/05/2005 ]

Алексей Федорчук (alv AT ginras.ru) - Archlinux: гармония гибкости и простоты   Версия для печати