Читать онлайн «Linux Mint и его Cinnamon. Очерки применителя». Страница 50

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

Вот их, как правило, поддаваясь смертному греху лености, и не программируют «с нуля». А объединяют соответствующие директивы в отдельные программные комплексы, именуемые библиотеками (libraries). Сами по себе они к автономному исполнению не пригодны. Однако любая программа, при необходимости совершить одно из типовых действий, вызывает из такой библиотеки некий фрагмент кода, содержащий требуемую последовательность директив.

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

Однако главной системной библиотекой список не исчерпывается. В UNIX-подобных системах при создании пользовательских интерфейсов используются библиотеки свойств терминала (например, ncurces) для консольных программ и библиотеки, описывающие процедуры отрисовки окон и управления ими — для графических программ системы X, библиотеки интерфейсных элементов и графических примитивов более высокого уровня (Motif, Qt, Gtk), библиотеки описания графических и мультимедийных форматов файлов и тому подобные «сборники». Иными словами, существует тенденция к вынесению в разделяемые библиотеки всех повторяющихся действий и элементов, какие только возможно.

Если библиотек, используемых в программах для консольного режима, не так много, они достаточно универсальны и легко поддаются учёту, то с библиотеками для обеспечения графического режима существенно сложнее. Даже простое перечисление их заняло бы немало места. Поэтому ограничусь констатацией факта, существенного для нашей темы. Обе основные рабочие среды дистрибутива Mint, MATE и Cinnamon, а также штатные приложения обеих редакций базируются на библиотеках Gtk — 2-й и 3-й версий, соответственно. К ним же примыкает и «левая» редакция с Xfce. И лишь KDE-редакция Mint основывается на библиотеках Qt и kdelibs. Поскольку основной героиней этого романа является Cinnamon, то дальше речь пойдёт в основном о пакетах, связанных зависимостями с библиотекой Gtk 3.

Как уже было сказано, в дистрибутиве Mint принят deb-формат пакетов. Будучи разработан ещё в прошлом тысячелетии для дистрибутива Debian, формат этот был унаследован от него Ubuntu, во многом предопределив успех последней. А вслед за ней — и удачливость нашего главного героя. Почему deb-формату и следует уделить некоторое внимание.

Пакет deb-формата — архивный файл (собранный утилитой ar, о которой недавно шла речь), включающий три компонента. Первый — это файлик debian-binary, не содержащий ничего, кроме номера версии deb-формата (в данный момент — 2.0).

Второй файл носит имя data.tar.xz и, как легко догадаться, представляет собой tar-архив, сжатый утилитой xz. Содержимое архива — скомпилированные исполняемые бинарники и необходимые им для работы компоненты (библиотеки, конфиги, документация и так далее). Иными словами, все компоненты, которые при установке пакета будут инкорпорированы в файловую иерархию целевой системы. Например, для пакета cinnamon_2.4.1+rebecca_amd64.deb в этом архиве обнаруживается каталог /usr с подкаталогами /usr/bin, /usr/lib, /usr/share, содержащими исполняемые бинарники, библиотеки и разделяемые компоененты, соответственно.

Третий файл именуется control.tar.gz и представляет собой архив файлов, содержащих всякого рода метаинформацию — описание пакета, его зависимости, классификационную принадлежность, приоритет и так далее (файл control), контрольные суммы всех исполняемых бинаников (файл md5sums), сценарии, выполняемые при установке и удалении пакета (preinst, postinst, prerm и postrm).

Зависимости в терминах deb-пакетов имеют несколько градаций: обязательные (depends), рекомендуемые (recommends), предлагаемые (suggests), конфликтующие (conflicts). Первая градация — это обычные «жёсткие» зависимости, без удовлетворения которых пакет либо не будет работать, либо вообще не установится. С градацией последней тоже понятно — это, так сказать, анти-зависимости: например, Opera текущей, 26-й, версии конфликтует с пакетом opera-12.16.

Ну а зависимости рекомендуемые и предлагаемые — это две разновидности «мягких» зависимостей. Разница между ними в том, что рекомендуемые пакеты обеспечивают «зависимому» пакету дополнительные функции (например, поддержку мыши в консольных приложениях), а пакеты предлагаемые предоставляют дополнительные возможности, вполне вероятно, полезные, но не жизненно необходимые (например, документацию, в том числе на не-английских языках). То есть первая категория как бы более нужная, нежели вторая. Впрочем, таково субъективное мнение майнтайнера конкретного пакета — вполне возможно, что у применителя будет своё мнение по этому поводу. И потому и пакетный менеджер apt, и его графическая «морда» Synaptic, устанавливающие зависимости автоматически, в Mint по умолчанию не делают этого ни для рекомендуемых, ни, тем более, для предлагаемых пакетов, а лишь выводят их список, дабы применитель сам принял решение по данному вопросу.

Кроме того, спецификой deb-пакетов является ещё и существование так называех пред-зависимостей (pre-depends) — при их нарушении установка пакета даже не может начаться, ибо их наличия требует пре-инсталляционный сценарий «зависящего» пакета. Впрочем, с точки зрения пользователя они немногим отличаются от обычных зависимостей типа depends.

Кроме зависимостей, для пакетов deb-формата важно также понятие их приоритета. Оно отражает степень необходимости пакета для функционирования системы, например: обязательный (required), без которого работа системы невозможна, основной (base) и важный (important), также оказывающиеся практически необходимыми, стандартный, то есть имеющийся практически в любой полнофункциональной Linux-системе, дополнительный (optional) — тут уж степень важности каждый должен решать для себя.

Как это принято в мире Open Source, все бинарные пакеты Mint (а также, конечно, Ubuntu и сородичей) сопровождаются исходными текстами, доступными из соответствующего репозитория дистрибутива. И здесь deb-формат проявляет свою специфику: каждый пакет в исходниках обычно включает три файла — packagename.orig.tar.gz, packagename.dsc и packagename.diff.gz.

Первый — самый обычный тарбалл исходных текстов авторского пакета, что подчеркивается словом orig в его имени: формат архива, имя и система нумерации версий также совпадают с таковыми авторского пакета. Файл packagename.dsc содержит в себе всю метаинформацию, необходимую для правильного построения из него бинарного deb-пакета. А packagename.diff.gz — это те изменения исходного кода, которые вносятся для адаптации пакета непосредственно к данному дистрибутиву. Если таких изменений не потребовалось (или если пакет писался именно для Ubuntu или Mint), он может и отсутствовать.

Пакеты, входящие в дистрибутив (или, если угодно, образующие дистрибутив), валяются не абы как — они организованы в репозитории. Что это такое?

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

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

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

Иными словами, пакеты в репозитории должны сопровождаться базами данных — теми самыми, которые используются системой управления пакетами данного дистрибутива.

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