Установка пакетов

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

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

Это не значит. что пакеты -- маленькие, размер их может быть самым разным. Как и состав -- есть пакеты, включающие фактически одну-единственную монофункциональную утилиту, есть пакеты, образованные набором программ определённой направленности. А есть -- и такие, которые сами по себе являются самостоятельной системой. Примером чему -- оконная система X (X Windows System) или, в просторечии, Иксы. Правда, майнтайнерами дистрибутивов она обычно разделяется на несколько пакетов.

В состав дистрибутива пакеты могут быть включены в трёх формах формах:

  • в виде т.н. исходных текстов (sources -- "исходников"), которые перед установкой и использованием подлежат определённым действиям -- трансформации в исполняемый код (процесс этот называется сборкой);
  • в виде набора правил для получения (из Сети) и сборки готовых к использованию пакетов из исходников -- так называемых портов, хотя в Linux такие наборы правил имеют собственные названия в каждом дистрибутиве; при этом сами исходники в состав дистрибутива входить не обязаны;
  • в виде заранее собранных, т.н. бинарных (или прекомпилированных) пакетов, которые необходимо только развернуть из архивов и поместить куда нужно.

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

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

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

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

Кроме того, проблема выбора осложняется ещё и явлением, известным под названием "зависимости пакетов". На практике это выглядит так, что выбор пакета A автоматически влечёт за собой также установку пакетов B и C -- количество зависимостей для каждого пакета может быть разным.

Существуют зависимости обязательные, или "жесткие", и опциональные, или "мягкие". Первые -- необходимы для установки и запуска инсталлируемого пакета. В большинстве случаев в эту категорию попадают т.н. системные библиотеки. Так, с главной системной библиотекой glibc в Linux (или её аналогом libc -- в BSD-системах) жёсткими зависимостями связаны абсолютно все (за редчайшим исключением) программы.

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

Как же установщики дистрибутивов позволяют решить пользователю проблему выбора и проблему зависимостей? Первая задача облегчается тем, что в большинстве инсталляторов предусмотрены некоторые предопределённые наборы пакетов (так называемые метапакеты), собранные в зависимости от целевого назначения системы: графическая рабочая станция, например, офисный или домашний компьютер, рабочее место программиста, web-, ftp- или файл-сервер, и так далее (количество и комплектация таких наборов варьирует в очень широких пределах). Ну а для тех, которые с претензиями и не хотят ходить, как все -- по камушкам, -- уважающие себя майнтайнеры дистрибутивов предлагают и ручной, попакетный, выбор компонентов.

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

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

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

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

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


Теги: ,