Пример 3.5. Сборка и установка программы с помощью make

desktop src # tar -xzf a-program-1.00.tar.gz

desktop src # cd a-program-1.00

desktop a-program-1.00 # make

... происходит компиляция и сборка программы ...

desktop a-program-1.00 # make install

... программа устанавливается в систему ...

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

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

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

Дальнейшее упрощение задач администратора в отношении отслеживания зависимостей и различий в реализации разных UNIX-систем в рамках той же модели — посредством сборочных процедур — предоставляют программы пакета autotools: automake и autoconf. Эти средства по существу реализуют адаптивные сборочные процедуры, которые способны настраиваться в зависимости от особенностей сборочной среды. Они позволяют на основе анализа присутствующих в системе программ и библиотек, особенностей операционной системы и аппаратной архитектуры автоматически получить make-файл, по которому будет произведена компиляция и установка программы.

Дистрибутивы

Презентация 8-03: виды дистрибутивов

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

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

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

Введение понятия пакет, помимо прочего, позволяет формализовать понятие зависимости: указывая в метаинформации пакета имена и версии других пакетов, от которых зависит данный. Таким образом, при установке пакета можно автоматически отслеживать наличие в системе всех необходимых для него комопонентов (других пакетов нужных версий), о чём ещё будет сказано далее (см. раздел «Задачи менеджера пакетов»).