Описание концепций Debian — Глава 2

Система Debian GNU/Linux сопровождается и распространяется в виде набора пакетов. Так как их стало очень много (свыше 2600), то для упрощения работы они поделены по разделам и приоритетам.

Цель проекта Debian — построить свободную операционную систему, но не каждый пакет, который мы хотим сделать доступным свободен в нашем понимании (смотри ниже Принципы Свободного Программного Обеспечения Debian), или что он может импортироваться/экспортироваться без ограничений. Поэтому, архив поделён на разделы main, non-us, non-free, и contrib.

Раздел main образовывает дистрибутив Debian GNU/Linux.

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

1. Разделы и авторские права на пакет

Основные концепции:

• Мы хотим сделать доступным как можно большее количество ПО.
• Мы хотим поддержать всех, кто пишет свободное ПО.
• Мы хотим сделать его легко доступным для людей выпуская CD-ROMы нашей системы без нарушения любых лицензий, ограничений по импорту/экспорту, или любых других законов.

1.1 Принципы Свободного Программного Обеспечения Debian

Принципы Свободного Программного Обеспечения Debian (The Debian Free Software Guidelines [DFSG]) — это наше определение `свободного’ ПО.

Свободное распространение

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

Исходный код

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

Производные работы

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

Сохранность авторского исходного кода

Лицензия может ограничивать исходный код от распространения в модифицированной форме только если лицензия позволяет распространение «патч файлов» вместе с исходным кодом для модификации программы во время сборки. Лицензия должна явно разрешать распространяемое ПО собирать из модифицированного исходного кода. Лицензия может требовать, чтобы производные работы имели другое имя или номер версии, отличающиеся от изначального ПО. (Это компромиссное решение. Группа Debian поощряет всех авторов, которые не ограничивают любые файлы, исходные или двоичные, от модификации.)

Никакой дискриминации в отношении отдельных личностей или групп

Лицензия должна иметь одинаковый подход к любому человеку или группе людей.

Никакой дискриминации в отношении областей применения

Лицензия не должна никого ограничивать при использовании программы определённой областью деятельности. Например, она не может запрещать использование программы в бизнесе или для генетических исследований.

Распространение лицензии

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

Лицензия не должна быть привязана к Debian

Авторские права, привязанные к программе, не должны зависеть от того, что она стала частью системы Debian. Если программа извлечена из Debian и используется или распространяется отдельно от Debian, но в иных пределах условий лицензии программы, то все компании, распространяющие программу, должны иметь те же права, когда программа предоставлялась с системой Debian.

Лицензия не должна влиять на другое ПО

Лицензия не должна содержать ограничения на другое ПО, которое распространяется с этим лицензионным ПО. Например, лицензия не должна требовать чтобы все другие программы распространялись тем же способом что и свободное ПО.

Примеры Лицензий

Лицензии «GPL,» «BSD,» and «Artistic»- это примеры лицензий, которые мы считаем свободными.

1.2. Раздел main

Каждый пакет в "main" должен подчиняться DFSG (Принципам Свободного Программного Обеспечения Debian).

Также, пакет в "main"

• не должен зависеть от пакетов не входящих в "main" для компиляции или выполнения (т.е., пакет не должен объявлять связи "Depends (Зависит от)" или "Recommends (Рекомендуется)" на не-main пакеты),
• должен быть не очень глючным, иначе мы откажемся поддерживать его
• должен удовлетворять всем необходимым правилам этого руководства.

1.3. Раздел contrib

Каждый пакет в "contrib" должен подчиняться DFSG (Принципам Свободного Программного Обеспечения).

Примеры пакетов, которые будут включаться в "contrib"

• свободные пакеты, которым необходимы для запуска или выполнения "contrib", "non-free", или "non-US" пакеты или любые пакеты, которых нет в нашем архиве,
• пакеты надстроек или другие виды свободных дополнений для non-free программ.

1.4. Раздел non-free

`Non-free’ содержит пакеты, которые противоречат DFSG или которые обременены патентами или другими юридическими тонкостями, что делает их распространение проблематичным.

Все пакеты в `non-free’ должны быть электронно распространяемыми через международные границы.

1.5. non-us сервер

Некоторые программы с криптографическим программным кодом должны содержаться на "не-us" сервере из-за экспортных ограничений U.S.

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

1.6. Дальнейшее обсуждение авторских прав

Каждый пакет должен сопровождаться дословной копией его авторских прав и лицензией распространения в файле /usr/share/doc/<имя-пакета>/copyright.

Мы оставляем за собой право не включать некоторые файлы в наши архивы если

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

Программы, чьи авторы подстрекают пользователя сделать пожертвование нормальны для дистрибутива main, если только авторы не утверждают что не сделать пожертвование аморально, неэтично, незаконно или подобно этому; иначе они должны перейти в contrib (или в non-free, если такими утверждениями ограничивается даже распространение).

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

Заметим, что международный закон об авторских правах (это так же применимо и в Соединённых Штатах) не позволяет распространение и модификацию работ без явного уведомления об этом. Поэтому программы без уведомления защищены авторским правом и ты не можешь ничего сделать с ними без риска стать преследуемым судом! Более того, если программа имеет уведомление об авторском праве, но нет формулировки о разрешении, то ничего не разрешено.

Многие авторы ничего не знают о проблемах, которые возникают из-за ограничительных авторских прав (или отсутствии уведомления об авторских правах) у пользователей их предположительно свободного ПО. Часто приходиться тратить время на связь с такими авторами, дипломатически прося изменить их условия лицензии. Однако, это политически трудно сделать и ты должен сначала попросить совет в debian-devel.

1.7 Подразделы

Пакеты в во всех разделах (main, contrib, non-US/main, non-free, non-US/contrib, и non-US/non-free) в дальнейшем образуют подразделы для простоты работы с ними.

Раздел каждого пакета указывается в контрольной записи пакета. Однако, сопровождающий архива Debian может изменить ее для обеспечения согласованности дистрибутива Debian.

Посмотри в текущем дистрибутиве Debian какие разделы сейчас существуют.

2. Приоритеты

Для каждого пакета определено значение приоритета, которое включается в контрольную запись пакета. Эта информация используется утилитой управления пакетами Debian для отделения очень важных пакетов от менее важных пакетов.

Следующие уровни приоритета поддерживаются системой управления пакетами Debian, dpkg.

required

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

important

important программы — это такие программы которые можно встретить в любой Unix-подобной системе. Предполагается, что если опытный в Unix человек чего-то не найдет, приговаривая `Что за фигня, где этот foo‘, то этот пакет наверняка лежит в important. Это важный критерий, потому что мы стараемся создать, помимо прочего, свободный Unix. Другие пакеты без которых система нормально не запустится или не будет рабочей должны также быть здесь. Сюда не включены Emacs, X Window System, TeX или любые другие большие приложения. Пакеты important — это только голый минимум обычно ожидаемых и необходимых утилит.

standard

Эти пакеты обеспечивают довольно маленькую, но уже не так ограниченную консольную систему. Она устанавливается по умолчанию, если пользователь не выбрал чего-то другого. В нее не включено много больших приложений, но она включает Emacs (это, по большей части, инфраструктура, чем приложение) и умеренное количество TeX и LaTeX (если возможно, то без X).

optional

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

extra

Здесь содержаться пакеты, которые конфликтуют с другими, имеющими required, important, standard или optional приоритеты, или только кажутся полезными, если ты уже знаешь о них или имеющие специальные требования.

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

3. Двоичные пакеты

Дистрибутив Debian GNU/Linux основан на системе управления пакетами Debian, называемой dpkg. Поэтому, все пакеты в дистрибутиве Debian поставляются в файловом формате .deb.

3.1. Название пакета

Каждый пакет должен иметь уникальное имя в архиве Debian.

Имена пакетов могут состоять только из символов нижнего регистра, цифр (0-9), знаков плюса (+) или минуса (-) и точек (.).

Имя пакета — это часть имени .deb файла и включается в контрольное поле.

3.2. Сопровождающий пакета

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

Сопровождающий должен быть указан в контрольном поле Maintainer правильным именем и рабочим email адресом сопровождающего пакет Debian. Если один человек сопровождает несколько пакетов, то он/она должен стараться избегать написания своего имени в различных формах и разные рабочие email адреса в различных полях Maintainer.

Если сопровождающий пакета покидает проект Debian, то Группа Debian QA берет на себя сопровождение пакета пока какой-нибудь из добровольцев не возьмется за эту работу. Такие пакеты называются зависшими пакетами.

3.3. Описание пакета

Каждый пакет Debian должен иметь расширенное описание, хранящееся в соответствующем поле контрольной записи.

Описание должно быть написано так, чтобы оно помогало пользователю понять нужно ли устанавливать этот пакет. Описание должно быть не просто копией начальной аннотации программы. Инструкции по настройке или использованию также не должны включаться — для этого есть сценарии установки, man страницы, Info файлы, и т.д. Заявления об авторских правах и другую административщину тоже сюда включать не нужно — для этого есть файл copyright.

3.4. Зависимости

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

Например, для динамически-линкуемых исполняемых файлов обеспечиваются записи о зависимостях от всех необходимых разделяемых библиотек.

Нет необходимости для других пакетов объявлять любые их зависимости от других пакетов, которые отмечены как Essential (смотри ниже).

Иногда, для установки пакета необходимо установить и настроить другой пакет. В этом случае, пакеты указываются в записи Pre-Depends.

Ты не должен указывать запись Pre-Depends для пакета, не обсудив его в списке рассылки debian-devel и пока об этом не будет достигнуто соглашение.

3.5. Виртуальные пакеты

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

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

Последнюю версию внушительного списка имен виртуальных пакетов можно найти на ftp.debian.org или на локальном зеркале. Также он включен в пакет debian-policy. Процедура обновления списка описана в начале файла.

3.6. Основные пакеты

Пакеты, включенные в раздел base, имеют специальное предназначение. Они составляют минимальный набор системы Debian GNU/Linux, который устанавливается перед установкой всего остального на новой системе. Поэтому, только очень немногим пакетам позволено находиться в разделе base, для того чтобы оставить используемое необходимое дисковое пространство очень маленьким.

Большинство этих пакетов должно иметь приоритет required или по крайней мере important, и многие из них помечены как essential (смотри ниже).

Ты не должен помещать любые пакеты в раздел base не обсудив этого в списке рассылки debian-develи пока об этом не будет достигнуто соглашение.

3.7. Важные пакеты

Некоторые пакеты помечены как essential. (В их контрольной записи стоит Essential: yes.) Этот флаг используется для пакетов, которые важны для системы.

Так как эти пакеты нелегко удалять (тебе нужно указать дополнительную опцию force для dpkg), этот флаг должен использоваться только когда он действительно необходим. Пакеты с разделяемыми библиотеками не должны помечаться как essential — зависимости предотвратят их преждевременное удаление, и мы будем иметь возможность удалить их когда необходимо будет их заменить.

Ты не должен помечать любые пакеты как essential перед тем как не обсудишь это в списке рассылки debian-devel и пока об этом не будет достигнуто соглашение.

3.8. Сопровождающие сценарии

Сценарии установки пакета должны избегать вывода, ненужного для пользователя и должны полагаться на dpkg по предотвращению скуки у пользователя, когда устанавливается много пакетов. Это состояние, кроме прочих, достигается включением опции --quiet у install-info.

Пакеты должны стараться минимизировать количество запрашиваемых необходимых им данных и они должны гарантировать, что пользователю не будут задаваться одинаковые вопросы. Это означает, что пакеты должны пытаться использовать соответствующие общие конфигурационные файлы (например, /etc/papersize и /etc/news/server), а не так чтобы каждый раз запрашивались общие для всех дополнительные необходимые данные.

Это также означает, что при переходе к новой версии те же самые вопросы будут задаваться вновь, если только пользователь не использовал dpkg --purge для удаления настроек пакета. Ответы на вопросы конфигурации должны сохраняться в соответствующее место в /etc так, чтобы пользователь мог изменять их и как, это должно быть описано.

Если пакет показывает пользователю жизненно важную часть информации (например, "не запускай меня сразу же, ты должен сначала отредактировать следующие файлы конфигурации или ты рискуешь, что твоя система начнёт ругаться плохими сообщениями"), то он должен отображать её из postinst сценария и просить пользователя нажать ввод, что до него дошло сообщение. Сообщения об авторских правах не считаются жизненно важными (они лежат в /usr/share/doc/пакет/copyright); так же как и инструкции по использованию программы (они должны быть в оперативно-доступной документации, там где пользователи смогут её найти).

Любый необходимый ввод данных почти всегда должен ограничиваться после-установочным сценарием, и должна быть гарантия, что ненужных запросов данных не будет, если установка пакета завершится неудачно и postinst вызывается с abort-upgrade, abort-remove или abort-deconfigure.

Ошибки, появляющиеся во время выполнения сценария установки должны отлавливаться и установка не должна продолжаться после ошибки.

Заметим, что сценарии, в общем, применим и к сопровождающим сценариям.

Не используй dpkg-divert к файлам, принадлежащим другим пакетам без консультации с сопровождающими этих пакетов.

Для правильной работы все пакеты, которые содержат экземпляр `разделяемой’ команды (или, вообще, имени файла) должны использовать update-alternatives. Ты можешь использовать Conflicts для вызова De-installation других пакетов, содержащих экземпляры, которые не используют (пока) update-alternatives. Это предназначается для того чтобы указать на конфликт с какими-нибудь более ранними версиями—это исключение из общего правила.

4. Пакеты с исходным кодом

4.1. Согласующие стандарты

Ты должен указывать наиболее новую версию стандарта которому соответствует пакет в поле Standards-Version пакетов с исходным кодом.

Это значение автоматически будет использовано в файле сообщений об ошибках, если твой пакет слишком сильно устареет.

Значения, соответствующие версиям руководств Debian, можно найти на титульной странице или в верхнем и нижнем колонтитулах (в зависимости от формата).

Номер версии состоит из четырех частей—старшего и младшего номера и старшего и младшего уровней модификации. Когда изменения в стандарте влекут за собой изменения в каждом пакете, то изменяется старший номер. Значительные изменения, которые влияют на работу многих пакетов, являются признаком изменения младшего номера. Старший уровень модификации изменяется при любых небольших изменениях стандарта; младший уровень модификации означает только косметические изменения, типографические или другие редактирования, которые не меняют смысл, или изменения, которые не влияют на содержимое пакетов.

Для сопровождающих значимы только первые 3 цифры из Standards-Version, или могут указываться полные 4 цифры—это решает сопровождающий.

Ты должен систематически, и особенно при устаревании пакета, проверять новое доступное Описание Концепций и обновлять пакет, если необходимо. Когда твой пакет согласован с новыми стандартами, то можно обновить поле Standards-Version исходного пакета и выпустить его.

4.2. Связи между пакетами

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

Нет нужды явно указывать связи для сборки с минимальным набором пакетов, которые всегда нужны для компиляции, линковки и сборки Debian пакета стандартной программы "Hello World!", написанной на C или C++. Необходимые пакеты находятся в build-essential, и их список можно найти в /usr/share/doc/build-essential/list (который содержится в пакете build-essential).

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

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

Это означает, в частности, что версии нужно проверять тщательнее в связях для сборки, так чтобы нельзя было получить плохие или несовместимо настроенные пакеты в то время как имеются рабочие взаимосвязи.

4.3. Изменения восходящих исходников

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

Если тебе нужно настроить пакет не под Debian или Linux, и восходящие исходники не умеют делать этого, то пожалуйста, добавь такие возможности (например, новый тест autoconf или #define) и пошли патч вышестоящим авторам, с их настройками по умолчанию. Затем ты можешь легко исправить настройки по умолчанию в своём debian/rules или в любом другом нужном месте.

Пожалуйста, проверь что утилита configure правильно определяет строку описания архитектуры.

Если тебе требуется отредактировать Makefile, который написан в GNU-стиле сценариев configure, то ты должен редактировать файлы .in, а не Makefile. Это позволит пользователю перенастроить пакет, если потребуется. Ты не должен настраиватьпакет и редактировать формируемый Makefile! Это сделает невозможным для других позже перенастроить пакет.

---

4.4. Документирование изменений

Документируй свои изменения и обновления исходного пакета должным образом в файле debian/changelog.

Копия файла, который будет установлен в /usr/share/doc/пакет/copyright должен быть в debian/copyright.

В не-экспериментальных пакетах ты можешь использовать только такой формат для debian/changelog, который поддерживается более новыми выпущенными версиями dpkg. Если твой формат не поддерживается и он широко распространен, то ты должен связаться с сопровождающим dpkg, чтобы сценарий синтаксического разбора стал понимать твой формат и был включен в пакет dpkg. Тебе нужно согласиться, что программа синтаксического разбора и ее man страница будет распространяться под GNU GPL, также как и dpkg.

4.5. Перехват ошибок в make-файлах

Когда make вызывает команды из makefile (включая вышестоящие make-файлы пакета и debian/rules), то при этом используется sh. Это означает, что sh неявно проводит обработку ошибок: если ты включил маленький сценарий как одну из команд в makefile, то обнаружится, что если ты сам не позаботишься об ошибках, то они не будут обнаружены и make слепо продолжит выполнение в случае проблемы.

Всякий раз когда ты помещаешь больше чем одну команду shell (включая использование циклов) в makefile, ты должен позаботиться о перехвате ошибок. Для составных простых команд, таких как смена каталога и затем запуск программы, в качестве разделителя достаточно использовать && вместо точки с запятой. Для более сложных команд, включающих циклы и условия, ты должен включать команду разделитель set -e в начало каждого makefile, который точно содержит один из таких маленьких сценариев shell.

4.6. Устаревшие конструкции и библиотеки

Включаемый файл <varargs.h> обеспечивает поддержку компиляции пользователями очень старого ПО; библиотека libtermcap осуществляет поддержку запуска ПО, слинкованного с ней (или старых программ или таких как Netscape, которые доступны только в двоичной форме).

Пакеты Debian должны портироваться под <stdarg.h> и ncurses во время сборки.