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

Изначально идея систематизации сборки программ, составляющих UNIX-систему, из исходных текстов развилась в BSD-системах (см. также «Системы, наследующие BSD»). В них (изначально во FreeBSD) было введено понятие порта — пакета специального вида, который сам не содержит исходных текстов, а только адрес их местонахождения (как правило, сайт разработчика), но содержит главную «точку приложения» знаний: дополнительные изменения, внесённые разработчиками дистрибутива, и формализованные инструкции по сборке.

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

Пример развития данной схемы до логического предела демонстрирует проект Linux From Scratch, — дистрибутив, который по существу не содержит вообще никаких текстов программ, а представляет собой обстоятельнейшую инструкцию для администратора, как самостоятельно скомпилировать все компоненты системы, начиная с средств разработки и ядра.

Среди широко используемых дистрибутивов GNU/Linux на сборке из исходных текстов основан Gentoo. Собственная, усовершенствованная версия портов, названная портежи (portages), позволяет сконфигурировать систему под конкретную задачу и даже специфическую архитектуру.

Рисунок 3.17. Распространение ПО в форме портов/портежей

Однако при таком распределении задач (компиляция на стороне администратора системы) сохраняется длительность процесса установки и зависимость от используемых средств разработки — даже на сервере приходится устанавливать компилятор gcc.

Дистрибутивы, основанные на двоичных пакетах

Презентация 8-04: из чего состоит пакет

Другим путём пошли разработчики многих дистрибутивов, основанных на распространении двоичных пакетов. Первые примеры использования двоичных пакетов в дистрибутивах Linux относятся к ранним версиям дистрибутивов Debian, RedHat и Slackware. Основное отличие подхода заключается в том, что системному администратору компоненты системы предлагаются не в виде пакетов с исходными текстами, а в виде пакетов, содержащих двоичные, скомпилированные версии программ. Таким образом с администратора системы снимается необходимость иметь средства разработки (сборочную среду) и тратить время на сборку программ. Более того, поскольку пакет содержит также и процедуры установки/удаления программы, основные задачи управления ПО становятся вполне доступными и пользователю, не имеющему специальной подготовки.

Описанные выше (см. раздел «Формы распространения программного обеспечения») проблемы, связанные с распространением двоичных программ, в логике таких дистрибутивов решены так: разработчики предоставляют дистрибутив, представляющий собой полноценную систему для решения определённого класса задач и поддерживающий определённый круг оборудования. Пользователю остаётся только выбрать подходящий дистрибутив и устанавливать и обновлять необходимые ему компоненты — пакеты. Работоспособность пакетов на данной аппаратной платформе, их интеграцию в системе, отслеживание зависимостей обеспечивают разработчики дистрибутива. Точнее, в рамках дистрибутива у каждого пакета традиционно имеется сопровождающий (package maintainer) или группа сопровождающих. Это ограничивает пользователя теми программами, что представлены в дистрибутиве. Установка любого ПО из других источников влечёт все описанные выше проблемы и требования для системного администратора или пользователя.

Рисунок 3.18. Распространение ПО в форме двоичных пакетов

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

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

С развитием Internet пакетные системы стали выносить на публику репозитарии пакетов — хранилище пакетов системы, содержащее «текущее состояние» системы, множетство всех пакетов и зависимостей между ними. Репозитарии удобны тем, что они находятся в «живом» состоянии — пакеты постоянно обновляются разработчиками дистрибутива и могут быть легко загружены и установлены пользователем. Как правило, для автоматизации и удобства работы с репозитарием (а именно, установки пакетов с удовлетворением всех зависимостей) используется специальная программа (например, APT). Имея постоянный доступ в Internet, можно развернуть всю систему из небольшого начального набора пакетов, включающего базовую систему и программу по работе с репозитарием.

Надо отметить, что акцент на двоичные пакеты в таких системах не мешает им также распространять пакеты с исходными текстами программ. Как структура таких пакетов, так и принципы работы с ними в основных чертах совпадают с портами и портежами в дистрибутивах, основанных на сборке из исходных текстов.

Существует несколько широко распространённых форматов пакетов, обычно связанных с различными дистрибутивами. Но в каждом из форматов будут присутствовать следующие логические составляющие (см. Рисунок 3.19, «Основные составляющие пакета»).

Рисунок 3.19. Основные составляющие пакета

название

Имя программы (например, apache) или функции, закреплённой за пакетом (например, basesystem — файлы и программы, составляющие основу системы).

версия

Версия программы, присвоенная разработчиками, обычно дополняется версией пакета в рамках дистрибутива (например, «pciutils-2.1.11-alt10»).

зависимости

Список пакетов с версиями, необходимых для установки и работы данного пакета. Как правило, пакеты в системе образуют решетку зависимостей.

автор(ы)

Имя и контактная информация автора или коллектива авторов программы, адрес домашней страницы проекта.

описание

Краткая (или не очень) информация о пакете — соответствующей программе или функции.

содежимое

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

Самые распространённые на данный момент дистрибутивы Linux — Debian и RedHat — являются типичным примерами систем с двоичными пакетами (rpm для RedHat и deb для Debian). Эти два формата пакетов используются также и в других дистрибутивах — Mandriva, ALT Linux, Ubuntu и т. д.