Понятие зависимостей

И для авторских, и для дистрибутивных пакетов очень важно понятие зависимостей. Суть его в том, что пакет pkgname1 для сборки, установки и (или) функционирования требует наличия в системе пакета pkgname2, тот, в свою очередь, может потребовать пакета pkgname3, и так далее.

Выделяются разные типы зависимостей. С одной стороны, различают зависимости при сборке (обычно называемые просто зависимостями -- depends) и зависимости при запуске (по английски именуемые run depends).

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

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

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

Так, для ряда консольных программ в Linux (таких, как файловый менеджер Midnight Commander или текстовый браузер links) существует возможность использования мыши в качестве указательно-позиционирующего устройства (а не только для выделения/вставки фрагментов из буфера экрана, как это имеет место в BSD-системах). Обеспечивается эта функция специальным сервисом -- gpm, при наличии которого и задействуется. Хотя сам по себе mc или links спокойно может функционировать и без неё.

В некоторых форматах бинарных пакетов (например, в deb - см. далее http://fossbook.info/packages/313) предусмотрено более дробное разделение "мягких" зависимостей -- например, на рекомендуемые и предлагаемые. Кроме того, часто приходится учитывать и так называемые конфликтующие зависимости -- то есть альтернативные по назначению пакеты, на способные ужиться в одной системе.

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

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

Возможно, разработчик Windows-программы с удовольствием последовал бы примеру своих FOSS-коллег. Однако исходники Windows-библиотек в большинстве своем закрыты и защищаются всякого рода проприетарными лицензиями, а в некоторых странах и патентами, препятствующими их свободному использованию. И потому Windows-разработчику волей-неволей приходится реализовывать требуемые ему функции самостоятельно. В результате чего программа, хотя и приобретает определённую самодостаточность, но зато разбухает в размерах: вспомним, сколько файлов вида *.dll устанавливает элементарный графический вьювер, идущий в комплекте со сканером или цифровой камерой.


Теги: ,