Критерии классификации дистрибутивов

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

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

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

Практически единственным чисто "исходнячным" дистрибутивом можно считать LFS (Linux from Scratch) Герарда Бикманса и варианты его многочисленных последователей - BLFS (Beyond Linux From Scratch - расширенный LFS для конечного пользователя), HLFS (Hardened Linux From Scratch - LFS повышенной секретности), CLFS (Cross Linux From Scratch - кросс-платформенный LFS). Однако характерно, что их пользователи, те, что не сделали сборку системы "с нуля" целью своей жизни, а используют их для практической работы, рано или поздно приходят к автоматизации процесса сборки посредством всякого рода самосочиненных скриптов, (субпроект ALFS - Automated Linux From Scratch, то есть автоматизированный LFS), получая в итоге очередные разновидности дистрибутивов портируемых. Именно таково происхождение RockLinux Клиффорда Вольфа - первого (1998 год) в истории дистрибутива, который можно было бы отнести к категории Source Based, возникшего до проекта LFS (и до появления самого термина, кстати говоря). Процесс "скриптизации" исходного LFS прекрасно описан Сергеем Каминским на его сайте).

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

Четкую грань между пакетными и портируемыми дистрибутивами провести нелегко. С одной стороны, развитые системы пакетного менеджмента подразумевает возможность построения пакета непосредственно из исходников. Правда, обычно эта возможность не является "сквозной" (то есть распространяемой на систему в целом). Но Debian и его производные (включая Ubuntu и Kubuntu) включают средства тотального пересбора системы, в чем мы убедимся в конце главы 9.

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

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

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

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

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