Формат контрольного файла - "control"

Файл "control", размещаемый в директории "DEBIAN" (в свою очередь, расположенной в директории с файлами для dpkg-deb) содержит информацию о пакете. Этот файл должен обязательно присутствовать в каждом deb-пакете. Каким он должен быть, описывается в справке deb-control(5), которая выводится, если набрать в терминале "man deb-control". На русском языке это описание можно посмотреть, например, в справке Ubuntu по адресу http://manpages.ubuntu.com/manpages/dapper/ru/man5/deb-control.5.html.

Файл "control" представляет из себя обычный текстовый файл в кодировке UTF-8.

Файл может содержать поля с информацией и комментарии. Строки, содержащие комментарии, должны начинаться с символа "#". Информация в них игнорируется программами, обрабатывающими пакеты, и нужна только для разработчиков. В начале полей с информацией должны находиться определённые тэги, описываемые ниже. Регистр тэга значения не имеет. Тэг отделяется от информации, записанной в поле, двоеточием. Информация в полях продолжается до следующего поля, то есть, может располагаться в нескольких строках. При сборке пакетов программа, которая собирает пакеты, обычно объединяет эти строки в одну, за исключением поля с тэгом "Description".

Обязательные поля

Обязательные поля должны содержаться в файле "control" каждого пакета. Начинаются они следующими тэгами.

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

Version - обычно в это поле записывается строка с версией - так, как её обозначает автор программы. Также версия может включать номер ревизии Debian (для пакетов, не распространяющихся вместе с системой). Если указывается номер версии программы и номер ревизии Debian, то они должны разделяться дефисом ("-"). Из-за этого версия программы не может содержать в себе дефис. Справка по правилам формирования номеров версий и правила их сортировки можно посмотреть в man-странице deb-version(5), которая выводится, если набрать в терминале "man deb-version". Если версия приложения состоит из двух-четырёх цифр, разделённых точками - можно не задумываться о правилах и написать версию такой, какая она есть.

Maintainer - фамилия, имя и адрес электронной почты человека, который собрал данный пакет (именно сборщика пакета, а не автора программы - если только автор программы не является и сборщиком пакета тоже). Сначала должно идти имя, набранное латинскими буквами, потом фамилия (также латинскими буквами), потом - адрес элемтронной почты в угловых скобках. Например, "Ivan Petroff <petroffi@somesite.ru>".

Description - описание. Краткое описание пакета должно размещаться в одной строке, идущей после тэга "Description". Все последующие строки за этой первой строкой будут использоваться как более детальное длинное описание - поэтому тэг "Description" должен быть самым последним тэгом в control-файле. Каждое поле детального описания должно начинаться с пробела. Если в описании нужно разместить пустую строку - она должна содержать одну точку ("."). После длинного описания должна идти одна строка, содержащая только пробел.

Необязательные поля

Этих полей в файле "control" может и не быть. Для некоторых пакетов установка некоторых полей вообще лишена смысла. Например, зачем заполнять поле "Conflicts" для пакета, который ни с чем не конфликтует?

Section - это общее поле, которое назначает для пакета секцию и категорию в зависимости от ПО, которое устанавливается при установке этого пакета. Секции и категории, как и всё прочее содержимое файла, пишутся на английском. Секция может писаться в формате "секция/категория". Секции обозначают разницу в лицензиях и доступности исходного кода для ПО, содержащегося в пакете. Секции различаются для разных дистрибутивов. Например, для Debian есть три секции, различающиеся соответствием размещаемого в них ПО критериям "Debian Free Software Guidelines (DFSG)" - "рекомендации Debian по свободному программному обеспечению". Это секции "main", "non-free", "contrib". main - основная секция, туда попадают все программы, соответствующие рекомендациям. Программы, не соответсвующие этим рекомендациям (с недоступным кодом, или имеющие лицензии с сильными ограничениями) размещаются в секции non-free. В секцию contrib попадают программы, соответсвующие DFSG, но имеющие какие-либо другие ограничения - например, зависящие от других программ, размещаемых в секции non-free. Более подробно об этом можно прочитать, например, на английской странице Википедии, посвящённой Debian: http://en.wikipedia.org/wiki/Debian#Additional_repositories, или на сайте Debian: http://www.debian.org/doc/manuals/developers-reference/resources.html#archive-sections.

В Ubuntu всё программное обеспечение делится на четыре секции, различающиеся по типу лицензий (свободное ПО/закрытое ПО или ПО с сильно ограниченными лицензиями) и по поддержке данного ПО компанией Canonical, развивающей дистрибутив Ubuntu. Эти секции - Main, в которой располагается свободное ПО, поддерживаемое Canonical; Universe - тоже свободное ПО, но не поддерживаемое Canonical; Restricted - поддерживаемое Canonical Несвободное ПО; Multiverse - несвободное и неподдерживаемое ПО. Определение свободного ПО в Ubuntu примерно соответствует принципам свободного программного обеспечения в Debian.

Если же ваш пакет собирается не для Debian или Ubuntu, а для какого-то другого дистрибутива, или если вы хотите, чтобы его можно было использовать в разных дистрибутивах - самым простым решением будет не указывать секцию, а указать только категорию ПО. Или даже вообще не заполнять поле Section - благо оно является необязательным.

Категории ПО, к одной из которых можно отнести содержимое пакета, для операционной системы Debian, перечислены в отдельном разделе: список категорий. Также их можно посмотреть на страницах официального сайта Debian. На русском: http://packages.debian.org/ru/sid/, на английском - http://packages.debian.org/en/sid/.

Priority - важность пакета. Различные значения, которые может принимать это поле, описываются на сайте Debian: http://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities. Значение, указанное в этом поле, используется утилитами для работы с пакетами для определения наиболее важных пакетов и отделения их от менее важных. Есть следующие значения приоритета, определяемые утилитами для работы с пакетами Debian:

  • required - "необходимые" (или, буквально, требуемые) пакеты. Это пакеты, необходимые для нормальной работы системы. Обычно, это означает, что утилита dpkg зависит от них. Удаление таких пакетов может сделать систему полностью неработоспособной, и вы даже не сможете использовать dpkg, чтобы починить систему. Поэтому удалять их можно только тогда, когда вы точно знаете, что делаете. Система, состоящая только из пакетов с приоритетом required, обычно нипригодна ни для каких дел, но содержит всё необходимое для того, чтобы загрузиться и установить больше программ.
  • important - "важные" пакеты. Важные программы, включая те, наличие которых ожидается на любой Unix-системе. Если предполагается, что для какого-то пакета опытный пользователь, не обнаруживший этого пакета в системе, воскликнет: "Что же творится на Земле, как может быть, чтобы в системе даже не было этого пакета?" - этот пакет можно отнести к важным. Другие пакеты, без которых система не будет хорошо работать, или будет малопригодна для использования, также должны быть отнесены к важным. Сюда не входят Emacs, X Window System, TeX или любые другие большие приложения. Важдые пакеты - это только необходимый минимум самых распространённых инструментов.
  • standard - "обычные" (или "стандартные") пакеты. Это пакеты, из которых создаётся небольшая, но не слишком ограниченная по функциональности система текстового режима. Это то, что будет установлено по умолчанию, если пользователь не выберет что-то ещё. Эти пакеты не включают много больших приложений.
  • optional - "необязательные" (ну или ещё можно сказать, опциональные) пакеты. (Можно было бы подумать, что всё, что не является необходимым, относится к необязательному, но это не то, что здесь имеется в виду.) Это все программы, которые вы можете захотеть установить, если вы не знаете, что это такое, и у них нет специальных требований. Их наличие сделает систему намного больше. В них входят X Window System, полный набор TeX, и много других программ. Замечание - необязательные пакеты не должны конфликтовать друг с другом.
  • extra - "дополнительные" пакеты. Сюда входят все пакеты, которые конфликтуют с другими пакетами, имеющими приоритет required, important, standard или optional. Или пакеты с программами, которые будут полезны только если вы точно знаете, дли чего они нужны и как с ними работать. Или пакеты, у которых имеются какие-то особые требования для использования. Например - пакеты, содержащие только отладочные символы.
Пакеты с большим приоритетом не должны зависеть от пакетов с приоритетом ниже (исключая зависимости, требующиеся только во время сборки). В случае, если такое происходит - возможно, надо скорректировать приоритет одного или нескольких пакетов.

Список значений, которые могут принимать поля Section и Priority, также можно получить, установив последнюю версию пакета debian-policy.

Essential - "пакет первой необходимости". Может принимать значения "yes" или "no" - то есть, "да" или "нет". Обычно, это поле нужно заполнять, только если его значение - "yes". Этим полем помечаются пакеты, необходимые для нормального функционирования системы. dpkg и другие инструменты для работы с пакетами не дают удалять такие пакеты - по крайней мере, пока им не передана какая-нибудь специальная опция наподобие "force".

Architecture - архитектура платформы, под которую скомпилирован пакет. Для бинарных пакетов, содержащих скомпилированные программы, это поле желательно указывать. Более подробно прочитать о ней можно на сайте Debian, по адресу http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-arch-spec. В это поле можно вписать архитектуру, или написать некоторые специальные значения ("wildcards"). Вообще-то, архитектуру правильно было бы указывать в формате os-arch, где "os" - это операционная система, а "arch" - архитектура процессора. Но, поскольку в большинстве случаев deb-пакеты собираются для Linux, часть "os" обычно пропускается. Полный список архитектур можно получить, выполнив в терминале команду "dpkg-architecture -L". Полученный мной список можно посмотреть в отдельном разделе: Поддерживаемые платформы. Большинство разработчиков, создающих программы для настольных компьютеров, компилирует их в первую очередь для 32-разрядных процессоров x86-совместимой архитектуры, обозначаемых в данном списке (а следовательно, и в пакетах) как "i386", и 64-разрядных процессоров той же архитектуры - x86-64 или amd64, которые в списке значатся как "amd64".
Специальные значения - это слова "all" и "any". Если написано "all" - это значит, что пакет независим от архитектуры, поэтому его можно использовать на всех архитектурах. Например, значение "all" подходит для пакетов на Perl или пакетов, содержащих документацию. Указание "any" также означает, что пакет годится для любой архитектуры. Но, "any" можно использовать и по-другому. Можно указать "os-any", где os - операционная система. Это будет означать, что пакет будет работать на любой архитектуре процессора, но в конкретной указанной операционной системе. И наоборот - можно указать "any-cpu", где cpu - тип процессора. Это будет означать, пакет можно использовать на любой операционной системе, но только для указанного типа процессора.

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

Depends - список пакетов, требующихся для нормальной работы пакета, описываемого данным control-файлом. Программа установки не позволит (по крайней мере, без использования специальных флагов) установить данный пакет, если пакеты, перечисленные в Depends, ещё не установлены. Если пакет устанавливается из репозитория, пакетный менеджер поддерживает автоматическое разрешение зависимостей, и перечисленные в поле "Depends" пакеты есть в подключенных репозиториях - будет предложено автоматически установить их. При установке скрипты postinst (то есть, выполняемые после установки) этих пакетов будут выполнены перед скриптом postinst данного пакета, а при удалении из системы скрипты prerm (то есть, выполняемые перед удалением) будут выполнены после скрипта prerm данного пакета.
Синтаксис указания пакетов для этого поля (как и для описываемых ниже полей Pre-Depends, Recommends, Suggests, Enhances) следующий. Пакеты разделяются символами "|" (вертикальная черта) и "," (запятая). "|" означает "или" - то есть, говорит, что подойдёт любой из разделяемых ей пакетов. Необязательно будет ставить их все. Запятая означает "и" - то есть, что нужны все разделяемые ей пакеты. "|" имеет более высокий приоритет.
Например, запись "packet_a | packet_b, packet_c, packet_d" означает, что этому пакету для нормального функционирования нужно, чтобы были установлены следующие пакеты: packet_c, packet_d, а также один из пакетов packet_a или packet_b.

После названия пакета можно в круглых скобках указать требуемую версию. После номера версии, также как и при указании версии пакета, можно указать номер ревизии Debian, отделяемый дефисом. Перед версией надо указать знак, который поясняет, как влияет указанная версия на то, какой пакет требуется. Можно указать, что подойдут все версии, больше чем указанная - для этого надо перед номером версии поместить знак ">>" (который здесь означает "больше"). Можно указать, что подойдут все версии, начиная с указанной (и включая её тоже) - для этого надо перед версией поместить знак ">=" (больше или равно). Чтобы сообщить пакетному менеджеру, что подойдут все версии меньше указанной, служит знак "" (меньше). Все версии, меньшие или равные указанной - знак "" (меньше или равно). Чтобы указать, что подойдёт только та версия, которая указана, надо перед версией в круглых скобках поместить знак "=" (равно). Например, чтобы указать, что для нормальной работы программы требуется пакет acme-base версии 1.2 или выше, надо написать: "acme-base (>= 1.2)".

Pre-Depends - список пакетов, которые должны быть не только установлены, но и сконфигурированы до установки данного пакета. Чаще всего, в этом списке указываются пакеты, нужные при выполнении скриптов preinst (то есть, включенных в пакет скриптов, выполняемых перед его установкой). Например, если ваш пакет включает выполняемый перед установкой скрипт, написанный на языке Perl, то для установки ему будет нужен установленный и настроенный Perl, и это надо указать, внеся в секцию Pre-Depends запись "perl". Синтаксис указания списка пакетов для этой секции такой же, как и для секции Depends.

Recommends - список пакетов, которые рекомендуется установить вместе с данным пакетом, но которые не являются необходимыми для его использования. Синтаксис указания списка пакетов для этой секции такой же, как и для секции Depends.

Suggests - список пакетов, которые возможно будут чем-то полезны при работе с данным пакетом. Синтаксис указания списка пакетов для этой секции такой же, как и для секции Depends.

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

Conflicts - список пакетов, которые конфликтуют с данным пакетом. Например, такое происходит, если два пакета устанавливают в одну и ту же директорию файл с одним и тем же именем. Пакетные менеджеры не позволяют устаналивать пакет, если для него есть конфликтующий пакет. Каждый из конфликтующих пакетов должен указать другой пакет в поле "Conflicts".

Синтаксис указания пакетов в поле Conflicts немного проще, чем в поле Depends - здесь не используется вертикальная черта ("|"), все пакеты перечисляются через запятую, которая читается как "или". То есть, перечисление "packet1, packet2, packet3" читается как "есть конфликт, если есть packet1, или packet2, или packet3". При наличии любого из перечисленных через запятую пакетов, пакетный менеджер будет не даст установить данный пакет. Для пакетов, перечисляемых в поле Conflicts, так же как и для поля Depends, можно указывать версию в круглых скобках.

Replaces - список виртуальных пакетов, предоставляемх данным пакетом. Обычно используется для того, чтобы позволить пакету переписать файлы другого пакета. Также обычно используется в комбинации с полем "Conflicts", чтобы инициировать удаление конфликтующего пакета, если он содержит такиже же файлы, как те, что устанавливаются данным пакетом. Синтаксис указания списка пакетов - такой же, как и для описываемого ниже поля Conflicts.

Provides - список виртуальных пакетов, предоставляемх данным пакетом. Обычно используется для того, чтобы несколько разных пакетов могли предоставлять одну и ту же функциональность Например пакеты sendmail и exim оба содержат почтовый сервер. Поэтому, оба они обеспечивают виртуальный пакет "mail-transport-agent". Другие пакеты, требующие установки почтового сервера, могут вместо перечисления в зависимостях через "|" sendmail и exim, а также других пакетов, содержащих почтовые серверы, просто указать, что они зависят от пакета "mail-transport-agent". Синтаксис указания списка пакетов - почти такой же, как и для описываемого ниже поля Conflicts. Отличается тем, что версию указывать здесь нельзя - указание версии для виртуальных пакетов смысла не имеет.

Built-Using - список пакетов с исходным кодом, которые использовались при сборке программы, содержащейся в данном пакете (если, конечно, он содержит скомпилированную программу). Этот список служит указанием для программ, поддерживающих архивы, на то, что перечисленные в списке пакеты должны сохраняться, пока используется собранный из них бинарный пакет. Для каждого пакета в списке должна точно указываться версия (то есть, со знаком "="). Программы поддержания архивов могут отказаться принимать загружаемый архив, если в нём не содержится пакетов, перечисленных в поле "Built-Using" одного из пакетов.

Пример control-файла:
# Comment
Package: grep
Essential: yes
Priority: required
Section: base
Maintainer: Wichert Akkerman <wakkerma@debian.org>
Architecture: sparc
Version: 2.4-1
Pre-Depends: libc6 (>= 2.0.105)
Provides: rgrep
Conflicts: rgrep
Description: GNU grep, egrep and fgrep.
 The GNU family of grep utilities may be the "fastest grep in the west".
 GNU grep is based on a fast lazy-state deterministic matcher (about
 twice as fast as stock Unix egrep) hybridized with a Boyer-Moore-Gosper
 search for a fixed string that eliminates impossible text from being
 considered by the full regexp matcher without necessarily having to
 look at every character. The result is typically many times faster
 than Unix grep or egrep. (Regular expressions containing backreferencing
 will run more slowly, however).