Файл "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:
Список значений, которые могут принимать поля 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).