
             Руководство начинающего разработчика Debian


---------------------------------------------------------------------
                                  
                            Джосип Родин

             первоначальный вариант <joy-mg@debian.org>

                             Осаму Аоки

               обновлённый вариант <osamu@debian.org>

L10N-russian

Russian Translation <debian-l10n-russian@lists.debian.org>

                         версия 1.2.53build1

---------------------------------------------------------------------

Авторские права © 1998-2002 Josip Rodin

Авторские права © 2005-2015 Osamu Aoki

Авторские права © 2010 Craig Small

Авторские права © 2010 Raphaël Hertzog

    This document may be used under the terms of the GNU General
    Public License version 2 or higher.

    Данный документ создан на основе следующих двух документов:

      * Making a Debian Package (AKA the Debmake Manual), copyright ©
        1997 Jaldhar Vyas.

      * The New-Maintainer's Debian Packaging Howto, copyright © 1997
        Will Lowe.

        The rewrite of this tutorial document with updated contents
        and more practical examples is available as "Guide for Debian
        Maintainers". Please use this new tutorial as the primary
        tutorial document.

2025-12-16 19:30:30 UTC

---------------------------------------------------------------------

Содержание

1. Хорошее начало — половина дела
    1.1. Социальная динамика Debian
    1.2. Программы, необходимые для разработки
    1.3. Документация, необходимая для разработки
    1.4. Где искать помощь
2. Первые шаги
    2.1. Порядок сборки пакета Debian
    2.2. Выбор программы
    2.3. Получение программы и ознакомление со сборкой
    2.4. Простые системы сборки
    2.5. Популярные переносимые системы сборки
    2.6. Имя и версия пакета
    2.7. Настройка dh_make
    2.8. Начальный неродной пакет Debian
3. Изменение исходного кода
    3.1. Настройка quilt
    3.2. Исправление ошибок в исходной программе
    3.3. Установка файлов в их каталоги назначения
    3.4. Несовпадение библиотек
4. Обязательные файлы в каталоге debian
    4.1. Файл control
    4.2. Файл copyright
    4.3. Файл changelog
    4.4. Файл rules
        4.4.1. Цели из файла rules
        4.4.2. Файл rules по умолчанию
        4.4.3. Доработка файла rules
5. Другие файлы в каталоге debian/
    5.1. Файл README.Debian
    5.2. Файл compat
    5.3. Файл conffiles
    5.4. Файлы пакет.cron.*
    5.5. Файл dirs
    5.6. Файл пакет.doc-base
    5.7. Файл docs
    5.8. Файлы emacsen-*
    5.9. Файл пакет.examples
    5.10. Файлы пакет.init и пакет.default
    5.11. Файл install
    5.12. Файл пакет.info
    5.13. Файл пакет.links
    5.14. Файлы {пакет.,source/}lintian-overrides
    5.15. Файлы manpage.*
        5.15.1. Файл manpage.1.ex
        5.15.2. Файл manpage.sgml.ex
        5.15.3. Файл manpage.xml.ex
    5.16. Файл пакет.manpages
    5.17. Файл NEWS
    5.18. Файлы {pre|post}{inst|rm}
    5.19. Файл пакет.symbols
    5.20. Файл TODO
    5.21. Файл watch
    5.22. Файл source/format
    5.23. Файл source/local-options
    5.24. Файл source/options
    5.25. Файлы patches/*
6. Сборка пакета
    6.1. Полная (пере)сборка
    6.2. Autobuilder
    6.3. Команда debuild
    6.4. Пакет pbuilder
    6.5. git-buildpackage command and similar
    6.6. Быстрая пересборка
    6.7. Иерархия команд
7. Проверка пакета на наличие ошибок
    7.1. Подозрительные изменения
    7.2. Проверка установки пакета
    7.3. Проверка сценариев сопровождающего пакета
    7.4. Использование lintian
    7.5. Команда debc
    7.6. Команда debdiff
    7.7. Команда interdiff
    7.8. Команда mc
8. Обновление пакета
    8.1. Новая редакция Debian
    8.2. Изучение нового авторского выпуска
    8.3. Новый авторский выпуск
    8.4. Обновление стиля пакетирования
    8.5. Преобразование в UTF-8
    8.6. Замечания по обновлению пакетов
9. Отправка пакета
    9.1. Отправка в архив Debian
    9.2. Включение файла orig.tar.gz для отправки
    9.3. Пропущенные отправки
A. Углублённое пакетирование
    A.1. Общие библиотеки
    A.2. Управление debian/пакет.symbols
    A.3. Мультиархитектурность
    A.4. Сборка пакета с общей библиотекой
    A.5. Родной пакет Debian

Глава 1. Хорошее начало — половина дела

    The rewrite of this tutorial document with updated contents and
    more practical examples is available as Guide for Debian
    Maintainers. Please use this new tutorial as the primary tutorial
    document.

    В этом документе описан процесс создания пакета Debian с точки
    зрения обычного пользователя и начинающего разработчика. Он
    написан простым языком и содержит работающие примеры. В этом
    руководстве мы пытаемся следовать старой латинской поговорке: 
    Longum iter est per praecepta, breve et efficax perexempla! (Путь
    длинен, если изучать правила, но короток и эффективен, если
    пользоваться примерами!).

    This document is made available for the Debian Buster release
    since this offers many translations. This document will be
    dropped in the following releases since contents are getting
    outdated. ^[1]

    Одна из сильных, по сравнению с другими дистрибутивами, сторон
    Debian — это система управления пакетами. Несмотря на то, что для
    Debian уже существует очень много пакетов, может случиться так,
    что вам понадобится установить программу, для которой не
    существует соответствующего пакета. Это может заставить вас
    задуматься о том, как создать свой собственный пакет. Для тех,
    кто делает первые шаги в Linux, это сложно, но вы к ним не
    относитесь, если сейчас читаете этот документ :-) Вам понадобятся
    некоторые знания о программировании под Unix, но ни в коем случае
    вы не обязаны быть гуру ^[2].

    Одно можно сказать определённо: создание и сопровождение пакетов
    Debian занимает много времени. Несомненно, чтобы наша система
    работала, сопровождающие должны быть технически грамотными и
    прилежными.

    If you need some help with packaging, please read Раздел 1.4,
    «Где искать помощь».

    Самые новые версии этого документа всегда доступны на странице
    http://www.debian.org/doc/maint-guide/ и в пакете maint-guide.
    Переводы доступны в отдельных пакетах, например maint-guide-es.
    Заметим, что данный документ может быть слегка устаревшим.

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

1.1. Социальная динамика Debian

    Вот некоторые наблюдения за социальной динамикой Debian,
    представленные в надежде, что это подготовит вас к взаимодействию
    с Debian:

      * Все занимаются Debian на добровольной основе.

          + Вы не можете указывать другим что делать.

          + Вы сами должны быть заинтересованы что-то делать.

      * Движущая сила — дружественное сотрудничество.

          + Ваш вклад не должен перенапрягать остальных.

          + Ваш вклад полезен, если так посчитают остальные.
   
      * Debian — это не школа, где вы автоматически получите внимание
        учителей.

          + Вы должны быть способны учиться самостоятельно.

          + Внимание других добровольцев — очень дефицитный ресурс.

      * Debian постоянно улучшается.

          + От вас ожидают высококачественных пакетов.

          + Вы сами должны адаптироваться к изменениям.

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

      * автор программы (upstream author) — человек, который создал
        программу.

      * сопровождающий программы (upstream maintainer) — человек,
        который сопровождает программу в настоящее время.

      * сопровождающий (maintainer) — человек, который создал для
        программы пакет Debian.

      * поручитель (sponsor) — человек, который помогает
        сопровождающим помещать пакеты в официальный архив пакетов
        Debian (после проверки их содержимого).

      * наставник (mentor) — человек, который помогает новым
        сопровождающим в пакетировании и т.п.

      * разработчик Debian (DD) — человек, являющийся участником
        проекта Debian. У него есть право на размещение пакетов в
        официальном архиве пакетов Debian.

      * сопровождающий Debian (DM) — человек, обладающий
        ограниченными правами на размещение пакетов в официальном
        архиве пакетов Debian.

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

    Заметим, что вам не нужно обязательно создавать новый пакет,
    чтобы стать официальным разработчиком Debian, для этого
    достаточно поддерживать существующие пакеты. Есть много пакетов,
    которые ждут хороших сопровождающих (смотрите Раздел 2.2, «Выбор
    программы»).

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

      * Debian: 17 лет Свободного ПО, «дело-кратия» и демократия
        (вступительные слайды)

      * Как помочь Debian? (официальная страница)

      * Часто задаваемые вопросы по Debian GNU/Linux, глава 13:
        «Содействие проекту Debian» (полуофициальная страница)

      * Страница HelpDebian в Debian Wiki (дополнительно)

      * Сайт нового сопровождающего Debian (официальный)

      * Список ответов на часто задаваемые вопросы наставникам Debian
        (дополнительно)

1.2. Программы, необходимые для разработки

    Перед тем как начать, нужно убедиться, что установлены все
    необходимые для разработки пакеты. Обратите внимание, что
    приведённый ниже список не содержит пакеты, помеченные как
    обязательные (essential) или требуемые (required) — считается,
    что эти пакеты уже установлены на вашей машине.

    The following packages come with the standard Debian
    installation, so you probably have them already (along with any
    additional packages they depend on). Still, you should check them
    with aptitude show package or with dpkg -s package.

    Самый важный пакет в системе разработчика — build-essential. Его
    установка повлечёт за собой загрузку других пакетов, требуемых
    для основы среды сборки.

    Кроме пакетов, требуемых для сборки любого пакета, есть пакеты,
    которые нужны только для некоторых пакетов; установите их, они
    могут пригодиться именно для вашего пакета:

      * autoconf, automake и autotools-dev — данные утилиты (смотрите
        info autoconf, info automake) используются во многих
        современных программах для создания сценариев настройки и
        файла Makefile. В пакете autotools-dev содержатся самые новые
        версии некоторых файлов auto- и документация по их
        применению.

      * debhelper и dh-make — пакет dh-make необходим для создания
        скелета нашего будущего пакета. Для этого он будет
        использовать некоторые инструменты из пакета debhelper.
        Использовать их необязательно, но мы очень рекомендуем их
        начинающим разработчикам. Они сильно упрощают процесс
        создания и поддержки пакетов (смотрите dh_make(8), debhelper
        (1)) ^[3].

        The new debmake may be used as the alternative to the
        standard dh-make. It does more and comes with HTML
        documentation with extensive packaging examples in
        debmake-doc.

      * devscripts — данный пакет содержит сценарии, полезные для
        сопровождающих, но так же не являющиеся необходимыми для
        сборки пакетов. Стоит обратить внимание на рекомендуемые и
        предлагаемые им пакеты (смотрите /usr/share/doc/devscripts/
        README.gz).

      * fakeroot - this utility lets you emulate being root, which is
        necessary for some parts of the build process. (See fakeroot
        (1).)

      * file — данная программа позволяет определить тип файла
        (смотрите file(1)).

      * gfortran — пакет содержит компилятор GNU Fortran; требуется,
        если программа написана на Fortran (смотрите gfortran(1)).

      * git — данный пакет предоставляет популярную систему контроля
        версий, разработанную для быстрого и эффективного
        сопровождения очень больших проектов; она используется во
        многих известных проектах с открытым кодом, наиболее заметным
        из которых является ядро Linux (смотрите git(1), руководство
        по git (/usr/share/doc/git-doc/index.html)).

      * gnupg - a tool that enables you to digitally sign packages.
        This is especially important if you want to distribute
        packages to other people, and you will certainly be doing
        that when your work gets included in the Debian distribution.
        (See gpg(1).)

      * gpc — пакет содержит компилятор GNU Pascal, который требуется
        при работе с программами, написанными на Pascal. Для этой
        задачи также хорошо подходит fp-compiler, Free Pascal
        Compiler (смотрите gpc(1), ppc386(1)).

      * lintian - this is the Debian package checker, which lets you
        know of any common mistakes after you build the package and
        explains the errors found. (See lintian(1), Lintian User's
        Manual.)

      * patch — данная утилита изменяет исходный файл в соответствии
        со списком различий между файлами, полученным при помощи
        программы diff (смотрите patch(1)).

      * patchutils — данный пакет содержит несколько утилит для
        работы с заплатами, например lsdiff, interdiff и filterdiff.

      * pbuilder - this package contains programs which are used for
        creating and maintaining a chroot environment. Building a
        Debian package in this chroot environment verifies the proper
        build dependency and avoids FTBFS (Fails To Build From
        Source) bugs. (see pbuilder(8) and pdebuild(1))

      * perl — один из наиболее используемых интерпретируемых языков
        в Unix-системах. Его часто называют «Unix's Swiss Army
        Chainsaw» (швейцарской армейской пилой) (смотрите perl(1)).

      * python — ещё один из наиболее используемых интерпретируемых
        языков в Debian, который объединяет необычайную мощь с очень
        понятным синтаксисом (смотрите python(1)).

      * quilt — пакет помогает управлять большими наборами заплат,
        отслеживая каждое сделанное изменение. Заплаты логически
        организуются в стек, и вы можете накладывать их, откатывать
        изменения, обновлять их и т.д. (смотрите quilt(1), /usr/share
        /doc/quilt/quilt.pdf.gz).

      * xutils-dev — пакет содержит программы, которые используются
        при сборке пакетов для X11, например с их помощью
        генерируется Makefile из набора макрофункций (смотрите imake
        (1), xmkmf(1)).

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

1.3. Документация, необходимая для разработки

    Кроме этого документа также очень важно прочитать следующую
    документацию:

      * debian-policy — в руководстве по политике Debian содержится
        описание структуры и содержимого архива Debian, некоторых
        проблем при разработке операционной системы, стандарт
        иерархии файловой системы (FHS, в котором оговаривается
        расположение каждого файла и каталога) и т.д. Также (что для
        вас важнее всего), в пакете указаны требования, которым
        должен удовлетворять каждый пакет Debian для того, чтобы он
        мог быть включён в дистрибутив (смотрите локальные файлы /usr
        /share/doc/debian-policy/policy.pdf.gz и /usr/share/doc/
        debian-policy/fhs/fhs-3.0.pdf.gz).

      * developers-reference - the Debian Developer's Reference
        describes all matters not specifically about the technical
        details of packaging, like the structure of the archive, how
        to rename, orphan, or adopt packages, how to do NMUs, how to
        manage bugs, best packaging practices, when and where to
        upload, etc. (See the local copy of /usr/share/doc/
        developers-reference/developers-reference.pdf.)

    Кроме этого документа также важно прочитать следующую
    документацию:

      * Autotools Tutorial provides a very good tutorial for the GNU
        Build System known as the GNU Autotools, whose most important
        components are Autoconf, Automake, Libtool, and gettext.

      * gnu-standards — в этом пакете содержатся две части
        документации проекта GNU: стандарты написания кода GNU и
        информация для сопровождающих ПО GNU . Хотя в Debian не
        требуется их соблюдения, они всё равно полезны для общего
        понимания (смотрите локальные файлы /usr/share/doc/
        gnu-standards/standards.pdf.gz и /usr/share/doc/gnu-standards
        /maintain.pdf.gz).

    Если этот документ в чём-то противоречит документам, упомянутым
    выше, это считается ошибкой. Отправьте сообщение об ошибке в
    пакете maint-guide с помощью reportbug.

    The following is an alternative tutorial document that you may
    read along with this document:

      * Учебник Debian по пакетированию

1.4. Где искать помощь

    Before you decide to ask your question in some public place,
    please read this fine documentation:

      * файлы в /usr/share/doc/пакет для всех используемых пакетов

      * содержимое man команда для всех используемых команд

      * содержимое info команда для всех используемых команд
   
      * содержимое архива списка рассылки
        debian-mentors@lists.debian.org

      * содержимое архива списка рассылки
        debian-devel@lists.debian.org

    Для более эффективного поиска с помощью поисковых машин добавьте
    в строку поиска site:lists.debian.org для ограничения по домену
    поиска.

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

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

      * в список рассылки debian-mentors@lists.debian.org (для
        новичков).

      * в список рассылки debian-devel@lists.debian.org (для опытных
        разработчиков).

      * на канале IRC, например в #debian-mentors.
   
      * Команды, работающие над определённым набором пакетов (полный
        список https://wiki.debian.org/Teams).

      * Списки рассылки на родном языке, например debian-devel-
        {french,italian,portuguese,spanish}@lists.debian.org или
        debian-devel@debian.or.jp (полный список https://
        lists.debian.org/devel.html и https://lists.debian.org/
        users.html).

    Более опытные разработчики Debian будут рады помочь вам, если на
    правильно зададите вопрос после попыток разобраться
    самостоятельно.

    Когда вы получите сообщение об ошибке (да, сообщения о реальных
    ошибках!), то знайте, что пришло время разобраться с системой
    отслеживания ошибок Debian и прочитать имеющуюся там
    документацию, чтобы эффективно работать с сообщениями об ошибках.
    Настоятельно рекомендуем прочитать справочник разработчика
    Debian, раздел 5.8. «Работа с ошибками».

    Even if it all worked well, it's time to start praying. Why?
    Because in just a few hours (or days) users from all around the
    world will start to use your package, and if you made some
    critical error you'll get mailbombed by numerous angry Debian
    users… Just kidding. :-)

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


---------------------------------------------------------------------

    ^[1] В документе предполагается, что вы используете jessie или
    более новую версию. Если у вас старая версия (включая старые
    выпуски Ubuntu и т.д.), установите современные версии пакетов
    dpkg и debhelper из специального репозитория (backports).

    ^[2] О том, как работать с системой Debian, можно найти в
    справочнике Debian. В нём также содержатся ссылки на материалы по
    программированию в системах Unix.

    ^[3] Существуют также похожие, более специализированные пакеты,
    такие как dh-make-perl, dh-make-php и т.д.

Глава 2. Первые шаги

    The rewrite of this tutorial document with updated contents and
    more practical examples is available as Guide for Debian
    Maintainers. Please use this new tutorial as the primary tutorial
    document.

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

2.1. Порядок сборки пакета Debian

    При создании пакета Debian из исходного кода программы в процессе
    сборки на каждом этапе генерируется несколько файлов со
    специальными именами:

      * получение копии исходного ПО, обычно в формате сжатого tar

          + пакет-версия.tar.gz
      * добавление специальных изменений Debian в исходную программу
        в каталог debian и создание неродного (non-native) пакета с
        исходным кодом (то есть, набора входных файлов, используемых
        для сборки пакета Debian) в формате 3.0 (quilt)

          + пакет_версия.orig.tar.gz
          + пакет_версия-редакция.debian.tar.gz^[4]
          + пакет_версия-редакция.dsc
      * сборка двоичных пакетов Debian для получения обычных файлов
        пакетов для установки в формате .deb (или в формате .udeb,
        который используется Debian Installer) из пакета Debian с
        исходным кодом

          + пакет_версия-редакция_архитектура.deb

    Заметим, что в именах файлов пакетов Debian для разделения пакета
    и версии используется символ _ (подчёркивание), а не - (дефис),
    как в имени оригинального tar-файла.

    В именах файлов, представленных выше, замените часть пакет на имя
    пакета, часть версия на версию исходной программы, часть редакция
    на редакцию Debian и часть архитектура на архитектуру, для
    которой предназначен пакет, в соответствии с политикой Debian ^
    [5].

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

2.2. Выбор программы

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

      * команду aptitude

      * веб-страницу пакетов Debian

      * the Debian Package Tracker web page

    Если пакет уже есть, то просто установите его! :-) Если случится
    так, что он окажется брошенным (orphaned) — то есть
    сопровождающий передал его Debian QA Group, то вы сможете
    подобрать его, если он ещё будет доступен. Также вы можете взять
    пакет, если его сопровождающий послал «запрос об усыновлении»
    (Request for Adoption, RFA) ^[6].

    Есть несколько ресурсов для получения информации о состоянии
    владения пакетом:

      * Команда wnpp-alert из пакета devscripts

      * Требующие доработки и будущие пакеты

      * Журналы сообщений об ошибках Debian: ошибки в псевдо-пакете
        wnpp в unstable

      * Пакеты Debian, которым нужна забота

      * Просмотр ошибок wnpp на основе категорий debtag

    Попутно отметим, что в Debian уже есть пакеты для большинства
    типов программ, и их количество в архиве Debian намного больше,
    чем участников с правом загрузки. Поэтому работа над пакетами,
    которые уже включены в архив, намного предпочтительней (и с
    большей вероятностью получит поручительство) с точки зрения
    других разработчиков ^[7]. Этого можно достичь различными путями:

      * подобрать брошенный, но пока активно используемый пакет

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

      * подготовить пакет для QA или NMU загрузки

    If you are able to adopt the package, get the sources (with
    something like apt-get source packagename) and examine them. This
    document unfortunately doesn't include comprehensive information
    about adopting packages. Thankfully you shouldn't have a hard
    time figuring out how the package works since someone has already
    done the initial setup for you. Keep reading, though; a lot of
    the advice below will still be applicable to your case.

    Если пакет новый и вы решили, что он нужен в Debian, то сделайте
    следующее:

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

      * You must check that no one else is already working on the
        package on the Work-Needing and Prospective Packages site. If
        no one else is working on it, file an ITP (Intent To Package)
        bug report to the wnpp pseudo-package using reportbug. If
        someone's already on it, contact them if you feel you need
        to. If not — find another interesting program that nobody is
        maintaining.

      * У программы обязательно должна быть лицензия.

          + Для секции main политика Debian требует, чтобы программа 
            удовлетворяла критериям Debian по определению Свободного
            ПО (DFSG) и не зависела от пакетов вне main для
            компиляции или выполнения. Это предпочтительный вариант.

          + Для секции contrib она должна удовлетворять DFSG, но
            может зависеть от пакетов вне main для компиляции или
            выполнения.

          + Для секции non-free она может не удовлетворять DFSG, но 
            должна быть распространяема.

          + Если вы не уверены в том, где должна размещаться
            программа, отправьте текст лицензии в
            debian-legal@lists.debian.org и попросите совета.

      * The program should not introduce security and maintenance
        concerns into the Debian system.

          + The program should be well documented and its code needs
            to be understandable (i.e., not obfuscated).

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

          + Программа определённо не должна требовать запуска с
            помощью setuid root, а ещё лучше — вообще не требовать
            прав доступа setuid или setgid к чему-либо.

          + Программа не должна работать как служба, размещаться в
            каталогах */sbin или открывать порты с правами root.

    Of course, the last one is just a safety measure, and is intended
    to save you from enraging users if you do something wrong in some
    setuid daemon… When you gain more experience in packaging, you'll
    be able to package such software.

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

      * Простые пакеты

          + одиночный двоичный пакет, архитектура = all (набор
            данных, например обои для рабочего стола)

          + одиночный двоичный пакет, архитектура = all (исполняемые
            файлы, написанные на интерпретируемых языках, таких как
            оболочка POSIX)

      * Пакеты средней сложности

          + одиночный двоичный пакет, архитектура = any (исполняемые
            двоичные файлы ELF, скомпилированные из исходного кода на
            C и C++)

          + несколько двоичных пакетов, архитектура = any + all
            (пакеты с исполняемыми двоичными файлами ELF +
            документация)

          + исходный код в формате, отличном от tar.gz или tar.bz2
   
          + исходный код с содержимым, не подлежащим распространению

      * Пакеты повышенной сложности

          + пакет для интерпретируемого модуля, используемого другими
            пакетами

          + пакет для обычной библиотеки ELF, используемого другими
            пакетами

          + несколько двоичных пакетов, включающих пакет с
            библиотекой ELF

          + исходный код, получаемый из нескольких источников

          + пакеты с модулями ядра

          + пакеты с заплатами к ядру

          + любой пакет со сложными сценариями сопровождающего

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

      * Политика для Perl

      * Политика для Python

      * Политика для Java

    There is another old Latin saying: fabricando fit faber (practice
    makes perfect). It is highly recommended to practice and
    experiment with all the steps of Debian packaging with simple
    packages while reading this tutorial. A trivial upstream tarball,
    hello-sh-1.0.tar.gz, created as follows may offer a good starting
    point:^[8]

    $ mkdir -p hello-sh/hello-sh-1.0; cd hello-sh/hello-sh-1.0
    $ cat > hello <<EOF
    #!/bin/sh
    # (C) 2011 Foo Bar, GPL2+
    echo "Hello!"
    EOF
    $ chmod 755 hello
    $ cd ..
    $ tar -cvzf hello-sh-1.0.tar.gz hello-sh-1.0

2.3. Получение программы и ознакомление со сборкой

    Итак, первое, что вы должны сделать — найти и скачать исходный
    код программы. Предполагается, что вы уже взяли файл с домашней
    страницы автора. Исходный код программ для Unix обычно
    предоставляется в виде архива в формате tar+gzip с расширением
    .tar.gz, tar+bzip2 с расширением .tar.bz2 или tar+xz с
    расширением .tar.xz. Внутри архива обычно есть каталог с именем
    пакет-версия, в котором находятся все файлы исходного кода
    программы.

    If the latest version of the source is available through a
    Version Control System (VCS) such as Git, Subversion, or CVS, you
    need to get it with git clone, svn co, or cvs co and repack it
    into tar+gzip format yourself by using the --exclude-vcs option.

    Если исходный код выбранной программы поставляется в другом виде
    (например, имя файла оканчивается на .Z или .zip^[9]), распакуйте
    его соответствующими средствами и перепакуйте его.

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

    В качестве примера взята программа gentoo — менеджер файлов,
    использующий GTK+ ^[10].

    В своём домашнем каталоге создайте каталог с именем debian, deb
    или с любым удобным (например, в нашем случае можно было бы
    использовать ~/gentoo). Поместите скачанный архив в этот каталог
    и распакуйте его (tar xzf gentoo-0.9.12.tar.gz). Убедитесь, что
    при этом не возникло никаких, даже, казалось бы, не относящихся к
    делу ошибок, так как их появление означает, что они могут
    возникнуть и на машинах других людей, у которых их инструменты
    распаковки посчитают это за реальную ошибку. В командной строке
    оболочки вы должны увидеть следующее:

    $ mkdir ~/gentoo ; cd ~/gentoo
    $ wget http://www.example.org/gentoo-0.9.12.tar.gz
    $ tar xvzf gentoo-0.9.12.tar.gz
    $ ls -F
    gentoo-0.9.12/
    gentoo-0.9.12.tar.gz

    В результате вы получите подкаталог gentoo-0.9.12. Перейдите в
    этот каталог и внимательно прочитайте имеющуюся документацию.
    Обычно, полезными оказываются файлы README*, INSTALL*, *.lsm или
    *.html. Вы должны найти инструкции, которые позволят вам
    правильно скомпилировать и установить программу (скорее всего, в
    каталог /usr/local/bin; вы должны будете установить программу в
    другой каталог, подробнее об этом в Раздел 3.3, «Установка файлов
    в их каталоги назначения»).

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

2.4. Простые системы сборки

    В простых программах обычно используется файл Makefile и для
    компиляции достаточно выполнить команду make^[11]. Некоторые из
    них поддерживают команду make check, по которой выполняется
    самопроверка. Установка в каталог назначения обычно выполняется с
    помощью make install.

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

    Вы также можете попытаться воспользоваться командой make clean
    (или лучше make distclean) для очистки каталога сборки. Иногда
    есть даже команда make uninstall, которая позволит удалить все
    установленные файлы.

2.5. Популярные переносимые системы сборки

    Многие свободные программы написаны на языках C и C++. В
    некоторых из них для переносимости между платформами используются
    Autotools или CMake. Эти инструменты используются для генерации
    Makefile и других необходимых исходных файлов. Такие программы
    обычно собираются с помощью make; make install.

    Autotools — это система сборки GNU, состоящая из Autoconf,
    Automake, Libtool и gettext. Её использование можно определить по
    включённым в исходный архив файлам configure.ac, Makefile.am и
    Makefile.in ^[12].

    Первый шаг автоматизации с помощью Autotools обычно выполняет
    автор программы. Он запускает команду autoreconf -i -f в каталоге
    с исходным кодом и затем распространяет сгенерированные файлы
    вместе с исходным кодом.

    configure.ac-----+-> autoreconf -+-> configure
    Makefile.am -----+        |      +-> Makefile.in
    src/Makefile.am -+        |      +-> src/Makefile.in
                              |      +-> config.h.in
                          automake
                          aclocal
                          aclocal.m4
                          autoheader

    Для правки файлов configure.ac и Makefile.am требуется знание
    инструментов autoconf и automake. Смотрите info autoconf и info
    automake.

    Второй шаг автоматизации с помощью Autotools обычно выполняет
    пользователь. Он получает распространяемый код и запускает ./
    configure && make для компиляции программы в исполняемыйдвоичный
    файл.

    Makefile.in -----+                +-> Makefile -----+-> make -> двоичный файл
    src/Makefile.in -+-> ./configure -+-> src/Makefile -+
    config.h.in -----+                +-> config.h -----+
                     |
      config.status -+
      config.guess --+

    Вы можете изменять различные переменные в файле Makefile.
    Например каталог установки по умолчанию изменяется с помощью
    параметра в командной строке: ./configure --prefix=/usr.

    Хотя это не обязательно, обновление configure и других файлов с
    помощью autoreconf -i -f может улучшить совместимость исходного
    кода ^[13].

    Альтернативной системой сборки является CMake. Её можно
    определить по наличию файла CMakeLists.txt.

2.6. Имя и версия пакета

    Если оригинальный исходный код программы содержится в файле
    gentoo-0.9.12.tar.gz, то в качестве (исходного) имени пакета
    можно взять gentoo, а в качестве версии исходной программы —
    0.9.12. Имя и версия используются в файле debian/changelog,
    который описан далее в Раздел 4.3, «Файл changelog».

    Although this simple approach works most of the time, you may
    need to adjust package name and upstream version by renaming the
    upstream source to follow Debian Policy and existing convention.

    You must choose the package name to consist only of lower case
    letters (a-z), digits (0-9), plus (+) and minus (-) signs, and
    periods (.). It must be at least two characters long, must start
    with an alphanumeric character, and must not be the same as
    existing packages. It is a good idea to keep its length within 30
    characters. ^[14]

    Если для имени автор программы использовал какие-то общие слова,
    например test-suite, то лучше назначить другое имя, которое явно
    описывает содержимое и не засоряет пространство имён ^[15].

    You should choose the upstream version to consist only of
    alphanumerics (0-9A-Za-z), plus signs (+), tildes (~), and
    periods (.). It must start with a digit (0-9). ^[16] It is good
    idea to keep its length within 8 characters if possible. ^[17]

    If upstream does not use a normal versioning scheme such as
    2.30.32 but uses some kind of date such as 11Apr29, a random
    codename string, or a VCS hash value as part of the version, make
    sure to remove them from the upstream version. Such information
    can be recorded in the debian/changelog file. If you need to
    invent a version string, use the YYYYMMDD format such as 20110429
    as upstream version. This ensures that dpkg interprets later
    versions correctly as upgrades. If you need to ensure smooth
    transition to the normal version scheme such as 0.1 in the
    future, use the 0~YYMMDD format such as 0~110429 as the upstream
    version.

    Строки версий ^[18] можно сравнить с помощь dpkg(1) следующим
    образом:

     $ dpkg --compare-versions версия1 операция версия2

    Правило сравнения версий вкратце можно описать так:

      * Строки сравниваются от начала к концу.

      * Буквы больше, чем цифры.

      * Числа сравниваются как целые.

      * Буквы сравниваются согласно порядку кодов ASCII.

      * Для символов точки (.), плюса (+) и тильды (~) правила
        следующие:

        0.0 < 0.5 < 0.10 < 0.99 < 1 < 1.0~rc1 < 1.0 < 1.0+b1 <
        1.0+nmu1 < 1.1 < 2.0

    Иногда бывает, что автор выпускает предварительную версию
    gentoo-0.9.12.tar.gz с именем
    gentoo-0.9.12-ReleaseCandidate-99.tar.gz. Чтобы правильно
    сработало обновление пакета, вам нужно переименовать файл с
    исходным кодом в gentoo-0.9.12~rc99.tar.gz.

2.7. Настройка dh_make

    Для указания вашего адреса электронной почты и имени, которые
    будут использоваться в пакетах инструментами сопровождения
    Debian, настройте переменные окружения $DEBEMAIL и $DEBFULLNAME ^
    [19]:

    $ cat >>~/.bashrc <<EOF
    DEBEMAIL="ваш.адрес.эл.почты@example.org"
    DEBFULLNAME="Имя Фамилия"
    export DEBEMAIL DEBFULLNAME
    EOF
    $ . ~/.bashrc

2.8. Начальный неродной пакет Debian

    Обычно, пакеты Debian являются неродными (non-native) пакетами
    Debian, создаваемыми из внешнего исходного кода. Если вы хотите
    создать неродной пакет Debian из исходного кода
    gentoo-0.9.12.tar.gz, то можете сгенерировать начальный неродной
    пакет Debian с помощью команды dh_make следующим образом:

    $ cd ~/gentoo
    $ wget http://example.org/gentoo-0.9.12.tar.gz
    $ tar -xvzf gentoo-0.9.12.tar.gz
    $ cd gentoo-0.9.12
    $ dh_make -f ../gentoo-0.9.12.tar.gz

    Здесь замените имя файла именем вашего архива с исходным кодом ^
    [20]. Подробней смотрите dh_make(8).

    You should see some output asking you what sort of package you
    want to create. Gentoo is a single binary package — it creates
    only one binary package, i.e., one .deb file — so we will select
    the first option (with the s key), check the information on the
    screen, and confirm by pressing ENTER. ^[21]

    После выполнения dh_make в родительском каталоге создался
    исходный архив tar с именем gentoo_0.9.12.orig.tar.gz, который в
    дальнейшем будет использоваться для создания неродного пакета с
    исходным кодом Debian с именем debian.tar.gz:

    $ cd ~/gentoo ; ls -F
    gentoo-0.9.12/
    gentoo-0.9.12.tar.gz
    gentoo_0.9.12.orig.tar.gz

    Отметьте два ключевых момента в имени файла
    gentoo_0.9.12.orig.tar.gz:

      * Имя пакета и версия разделены символом _ (подчёркивание).
   
      * Перед .tar.gz есть часть .orig.

    Вы, наверное, уже заметили, что в исходном коде в каталоге debian
    было создано множество файлов шаблонов. Их назначение описано в
    Глава 4, Обязательные файлы в каталоге debian и Глава 5, Другие
    файлы в каталоге debian/. Как вы уже догадались, процесс
    пакетирования не может быть полностью автоматическим. Вам нужно
    изменить исходный код программы для Debian (Глава 3, Изменение
    исходного кода). После этого вам нужно правильно собрать пакет
    Debian (Глава 6, Сборка пакета), проверить его (Глава 7, Проверка
    пакета на наличие ошибок) и отослать в архив (Глава 9, Отправка
    пакета). Далее будут рассмотрены все эти шаги.

    Если вы случайно стёрли какой-то файл шаблона при работе, то
    можете восстановить его, повторно запустив dh_make с параметром
    --addmissing в дереве исходного кода пакета Debian.

    Обновлять существующий пакет сложнее, так как для его создания
    могли использоваться старые методы. Поэтому на время обучения
    пока беритесь за современные пакеты. Мы вернёмся к этому позднее
    в Глава 8, Обновление пакета.

    Please note that the source file does not need to contain any
    build system discussed in Раздел 2.4, «Простые системы сборки»
    and Раздел 2.5, «Популярные переносимые системы сборки». It could
    be just a collection of graphical data, etc. Installation of
    files may be carried out using only debhelper configuration files
    such as debian/install (see Раздел 5.11, «Файл install»).


---------------------------------------------------------------------

    ^[4] В старом формате 1.0 для неродных пакетов Debian с исходным
    кодом использовалось имя пакет_версия-редакция.diff.gz.

    ^[5] Смотрите описание полей 5.6.1 «Source», 5.6.7 «Package» и
    5.6.12 «Version». Значение архитектуры пакета задаётся согласно
    политике Debian в разделе 5.6.8, «Architecture» и автоматически
    назначается в процессе сборки пакета.

    ^[6] See Debian Developer's Reference 5.9.5 "Adopting a package".

    ^[7] С другой стороны, всегда будут появляться новые программы,
    которые хотелось бы иметь в виде пакета.

    ^[8] Не беспокойтесь об отсутствии файла Makefile. Вы можете
    установить команду hello просто с помощью debhelper, как показано
    в Раздел 5.11, «Файл install», или изменить исходный код, добавив
    новый Makefile с целью install, как показано в Глава 3, Изменение
    исходного кода.

    ^[9] Вы можете определить формат архива с помощью команды file,
    если по расширению это непонятно.

    ^[10] Для этой программы пакет уже создан. В текущей версии в
    качестве структуры сборки используется Autotools и,
    следовательно, есть различия с приводимыми примерами, которые
    были написаны для версии 0.9.12.

    ^[11] Many modern programs come with a script named configure,
    which when executed creates a Makefile customized for your
    system.

    ^[12] Autotools is too big to deal with in this small tutorial.
    This section is meant to provide keywords and references only.
    Please make sure to read the Autotools Tutorial and the local
    copy of /usr/share/doc/autotools-dev/README.Debian.gz, if you
    need to use it.

    ^[13] Вы можете это автоматизировать с помощью пакета
    dh-autoreconf. Смотрите Раздел 4.4.3, «Доработка файла rules».

    ^[14] В aptitude длина поля имени пакет по умолчанию равна 30.
    Длина имён более чем 90% пакетов менее 24 символов.

    ^[15] If you follow the Debian Developer's Reference 5.1. "New
    packages", the ITP process will usually catch this kind of issue.

    ^[16] Это жёсткое правило должно помочь избежать путаницы в
    именах файлов.

    ^[17] В aptitude длина поля версии по умолчанию равна 10.
    Редакция Debian с символом переноса обычно занимает 2 символа. В
    более 80% пакетов версия исходной программы — менее 8 символов, а
    редакция Debian — менее 2 символов. В более 90% пакетов версия
    исходной программы — менее 10 символов, а редакция Debian — менее
    3 символов.

    ^[18] Строками версий могут быть версия исходной программы (
    версия), редакция Debian (редакция) или версия (версия-редакция).
    Смотрите в Раздел 8.1, «Новая редакция Debian» как увеличивается
    значение редакции Debian.

    ^[19] В примере предполагается, что в качестве регистрационной
    оболочки у вас используется Bash. Если вы используете другую
    регистрационную оболочку (например, Z shell), используйте другие
    соответствующие файлы настройки вместо ~/.bashrc.

    ^[20] If the upstream source provides the debian directory and
    its contents, run the dh_make command with the extra option
    --addmissing. The new source 3.0 (quilt) format is robust enough
    not to break even for these packages. You may need to update the
    contents provided by the upstream version for your Debian
    package.

    ^[21] Здесь предлагается несколько вариантов: s — одиночный
    двоичный пакет, i — пакет, независящий от архитектуры, m —
    несколько двоичных пакетов, l — пакет для библиотеки, k — пакет
    для модуля ядра, n — пакет с заплатами к ядру и b — пакет,
    применяющий cdbs. В этом документе, в основном, описывается
    использование команды dh (из пакета debhelper) для создания
    одиночного двоичного пакета, но также затрагиваются варианты с
    пакетами, независящими от архитектуры, и когда из одной программы
    создаётся несколько двоичных пакетов. Пакет cdbs предоставляет
    инфраструктуру пакетирования альтернативную команде dh и не
    описан в этом документе.

Глава 3. Изменение исходного кода

    The rewrite of this tutorial document with updated contents and
    more practical examples is available as Guide for Debian
    Maintainers. Please use this new tutorial as the primary tutorial
    document.

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

3.1. Настройка quilt

    Программа quilt предлагает простой способ записи изменений,
    произведённых в исходном коде для пакетирования Debian. Для
    удобства использования слегка изменим настройки по умолчанию,
    добавив для пакетирования псевдоним dquilt в файле ~/.bashrc.
    Вторая строка служит для включения автодополнения к dquilt,
    такого же как у команды quilt:

    alias dquilt="quilt --quiltrc=${HOME}/.quiltrc-dpkg"
    . /usr/share/bash-completion/completions/quilt
    complete -F _quilt_completion -o filenames dquilt

    Затем создадим файл ~/.quiltrc-dpkg со следующим содержимым:

    d=. ; while [ ! -d $d/debian -a $(readlink -e $d) != / ]; do d=$d/..; done
    if [ -d $d/debian ] && [ -z $QUILT_PATCHES ]; then
        # if in Debian packaging tree with unset $QUILT_PATCHES
        QUILT_PATCHES="debian/patches"
        QUILT_PATCH_OPTS="--reject-format=unified"
        QUILT_DIFF_ARGS="-p ab --no-timestamps --no-index --color=auto"
        QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index"
        QUILT_COLORS="diff_hdr=1;32:diff_add=1;34:diff_rem=1;31:diff_hunk=1;33:diff_ctx=35:diff_cctx=33"
        if ! [ -d $d/debian/patches ]; then mkdir $d/debian/patches; fi
    fi

    О том, как использовать quilt, читайте в quilt(1) и /usr/share/
    doc/quilt/quilt.pdf.gz.

3.2. Исправление ошибок в исходной программе

    Let's assume you find an error in the upstream Makefile as
    follows, where install: gentoo should have been install:
    gentoo-target.

    install: gentoo
            install ./gentoo $(BIN)
            install icons/* $(ICONS)
            install gentoorc-example $(HOME)/.gentoorc

    Внесём исправление и запишем его при помощи команды dquilt в файл
    fix-gentoo-target.patch ^[22]:

    $ mkdir debian/patches
    $ dquilt new fix-gentoo-target.patch
    $ dquilt add Makefile

    Изменим файл Makefile следующим образом:

    install: gentoo-target
            install ./gentoo $(BIN)
            install icons/* $(ICONS)
            install gentoorc-example $(HOME)/.gentoorc

    Запустите dquilt для генерации и записи заплаты в файл debian/
    patches/fix-gentoo-target.patch и добавьте к ней описание в
    соответствии с DEP-3: Руководство по маркировке заплат:

    $ dquilt refresh
    $ dquilt header -e
    ... описание заплаты

3.3. Установка файлов в их каталоги назначения

    Большинство стороннего ПО устанавливает себя в иерархию каталогов
    /usr/local. В Debian это место зарезервировано для использования
    администратором по своему усмотрению, поэтому пакеты не должны
    использовать такие каталоги как /usr/local/bin, а должны
    устанавливаться в системные каталоги, такие как /usr/bin,
    согласно стандарту иерархии файловой системы (FHS).

    Обычно, для автоматизации сборки программы используется make(1),
    а по команде make install выполняется установка программ в
    желаемый каталог, назначенный для цели install в файле Makefile.
    Для создания двоичных, готовых к установке пакетов Debian,
    требуется изменить систему сборки таким образом, чтобы она
    устанавливала программы в образ файловой системы, развёрнутый во
    временном каталоге, а не в реальное место назначения.

    Эти два различия между нормальной установкой программы, с одной
    стороны, и системой пакетирования Debian с другой, могут быть
    прозрачно переданы пакетом debhelper с помощью команд 
    dh_auto_configure и dh_auto_install, если соблюдаются следующие
    условия:

      * Файл Makefile соответствует соглашениям GNU и поддерживает
        переменную $(DESTDIR) ^[23].

      * Исходный код следует FHS.

    Программы, использующие пакет GNU autoconf, автоматически следуют
    соглашениям GNU, и их легко пакетировать. На основе этого и
    эвристики можно сделать вывод, что пакет debhelper будет работать
    с почти 90% пакетов без внесения серьёзных изменений в их системы
    сборки. Поэтому процесс пакетирования не так сложен, как кажется.

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

    При создании из исходного кода одиночного пакета временный
    каталог, используемый командой dh_auto_install, будет установлен
    в debian/пакет ^[24]. Всё, что содержится во временном каталоге,
    будет помещено в систему пользователя при установке пакета.
    Различие в том, что dpkg установит файлы в систему относительно
    корневого каталога, а не вашего рабочего каталога.

    Помните: даже если ваша программа устанавливается в debian/пакет,
    нужно внимательно следить за правильностью её установки из пакета
    .deb в корневой каталог. Поэтому вы не должны разрешать системе
    сборки записывать неизменяемые строки вроде /home/моего/deb/пакет
    -версия/usr/share/пакет в файлы пакета.

    Вот соответствующая часть файла Makefile, взятого из пакета
    gentoo^[25]:

    # Куда помещать исполняемые файлы по команде «make install»?
    BIN     = /usr/local/bin
    # Куда помещать значки по команде «make install»?
    ICONS   = /usr/local/share/gentoo

    We see that the files are set to install under /usr/local. As
    explained above, that directory hierarchy is reserved for local
    use on Debian, so change those paths as follows:

    # Куда помещать исполняемые файлы по команде «make install»?
    BIN     = $(DESTDIR)/usr/bin
   
    # Куда помещать значки по команде «make install»?
    ICONS   = $(DESTDIR)/usr/share/gentoo

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

    Итак, исполняемые файлы следует устанавливать в /usr/bin вместо /
    usr/local/bin, справочные страницы в /usr/share/man/man1 вместо /
    usr/local/man/man1 и т.д. Обратите внимание, что хотя в Makefile
    из пакета gentoo отсутствует упоминание о справочной странице,
    Debian Policy требует её наличия для каждой программы, поэтому
    позднее мы создадим такую страницу и установим её в /usr/share/
    man/man1.

    Некоторые программы не используют переменные в Makefile для
    подобного указания путей. Это означает, что, возможно, вам
    придётся редактировать исходные файлы, написанные на языке C, для
    указания правильного расположения. Но где и как искать эти пути?
    Для этого вы можете воспользоваться следующей командой:

    $ grep -nr --include='*.[c|h]' -e 'usr/local/lib' .

    Команда grep рекурсивно обходит всё дерево исходного кода и при
    обнаружении совпадений сообщает вам имя соответствующего файла и
    номер строки.

    Отредактируйте указанные строки в этих файлах, заменив usr/local/
    lib на usr/lib. Это можно сделать автоматически с помощью
    команды:

    $ sed -i -e 's#usr/local/lib#usr/lib#g' \
            $(find . -type f -name '*.[c|h]')

    Если вы хотите подтверждать каждую замену, запустите следующую
    команду:

    $ vim '+argdo %s#usr/local/lib#usr/lib#gce|update' +q \
            $(find . -type f -name '*.[c|h]')

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

    Первоначально, цель install в gentoo была такой:

    install: gentoo-target
            install ./gentoo $(BIN)
            install icons/* $(ICONS)
            install gentoorc-example $(HOME)/.gentoorc

    Давайте исправим ошибку с путями в исходной программе и запишем
    её при помощи команды dquilt в файл debian/patches/install.patch.

    $ dquilt new install.patch
    $ dquilt add Makefile

    Воспользуемся редактором для внесения в пакет Debian следующих
    изменений:

    install: gentoo-target
            install -d $(BIN) $(ICONS) $(DESTDIR)/etc
            install ./gentoo $(BIN)
            install -m644 icons/* $(ICONS)
            install -m644 gentoorc-example $(DESTDIR)/etc/gentoorc

    Разумеется вы заметили, что в начале цели появилась команда
    install -d. В исходном Makefile её не было, так как обычно /usr/
    local/bin и другие каталоги уже существуют в системе на момент
    запуска make install. Однако, так как мы будем проводить
    установку в создаваемый каждый раз свой каталог, нам следует
    создать в нём все необходимые каталоги.

    В конец правила установки мы можем добавить что-нибудь ещё,
    например, установку дополнительной документации, которую не
    включили авторы программы:

            install -d $(DESTDIR)/usr/share/doc/gentoo/html
            cp -a docs/* $(DESTDIR)/usr/share/doc/gentoo/html

    Убедившись, что всё сделано правильно, c помощью dquilt
    сгенерируем заплату debian/patches/install.patch и добавим её
    описание:

    $ dquilt refresh
    $ dquilt header -e
    ... описание заплаты

    Теперь у вас есть несколько заплат:

     1. Заплата для исправления ошибки в программе: debian/patches/
        fix-gentoo-target.patch
   
     2. Изменения, необходимые для создания пакета Debian: debian/
        patches/install.patch

    Whenever you make changes that are not specific to the Debian
    package such as debian/patches/fix-gentoo-target.patch, be sure
    to send them to the upstream maintainer so they can be included
    in the next version of the program and be useful to everyone
    else. Also remember to avoid making your fixes specific to Debian
    or Linux — or even Unix! Make them portable. This will make your
    fixes much easier to apply.

    Не отправляйте разработчикам программы файлы debian/*.

3.4. Несовпадение библиотек

    There is one other common problem: libraries are often different
    from platform to platform. For example, a Makefile can contain a
    reference to a library that doesn't exist on the Debian system.
    In that case, we need to change it to a library that does exist
    in Debian, and serves the same purpose.

    Предположим, что в программе есть Makefile (или Makefile.in) со
    строкой следующего вида:

    LIBS = -lfoo -lbar

    Если ваша программа не компилируется из-за отсутствия библиотеки
    foo и в Debian для неё есть замена в виде foo2, то вы можете
    исправить проблему со сборкой с помощью debian/patches/
    foo2.patch, который заменяет foo на foo2:^[26]

    $ dquilt new foo2.patch
    $ dquilt add Makefile
    $ sed -i -e 's/-lfoo/-lfoo2/g' Makefile
    $ dquilt refresh
    $ dquilt header -e
    ... описание заплаты


---------------------------------------------------------------------

    ^[22] Каталог debian/patches уже должен существовать, если вы
    запускали dh_make, как это описывалось ранее. В этом примере
    каталог создаётся вручную, на случай если обновляется
    существующий пакет.

    ^[23] Смотрите Стандарты программирования GNU: 7.2.4 DESTDIR:
    Поддержка поэтапной установки.

    ^[24] При создании из исходного кода нескольких двоичных пакетов
    команда dh_auto_install использует debian/tmp в качестве
    временного каталога, а команда dh_install с помощью файлов debian
    /пакет-1.install и debian/пакет-2.install разнесёт содержимое
    debian/tmp по временным каталогам debian/пакет-1 и debian/пакет-2
    для создания двоичных пакетов пакет-1_*.deb и пакет-2_*.deb.

    ^[25] Это просто пример, который показывает как должен выглядеть
    Makefile. Если Makefile создан командой ./configure, то
    исправлять файл Makefile предпочтительно вызовом ./configure из 
    dh_auto_configure с параметрами по умолчанию и добавленным
    параметром --prefix=/usr.

    ^[26] Если изменяется программный интерфейс (API) (то есть,
    вместо библиотеки foo начинают использовать библиотеку foo2), то
    требуется изменить исходный код так, чтобы он использовал новый
    API.

Глава 4. Обязательные файлы в каталоге debian

    The rewrite of this tutorial document with updated contents and
    more practical examples is available as Guide for Debian
    Maintainers. Please use this new tutorial as the primary tutorial
    document.

    В каталоге c исходным кодом программы появился новый подкаталог
    debian. В нём содержится несколько файлов, которые нужно
    отредактировать для изменения свойств пакета. Наиболее важные из
    них: control, changelog, copyright и rules; они обязательны для
    всех пакетов ^[27].

4.1. Файл control

    Этот файл содержит информацию, которая используется программами 
    dpkg, dselect, apt-get, apt-cache, aptitude и некоторыми другими
    инструментами для работы c пакетами. Он описан в руководстве по
    политике Debian, в главе 5 «Управляющие файлы и их поля».

    Вот, например, файл control, который был создан для нас
    программой dh_make:

     1 Source: gentoo
     2 Section: unknown
     3 Priority: optional
     4 Maintainer: Josip Rodin <joy-mg@debian.org>
     5 Build-Depends: debhelper (>=10)
     6 Standards-Version: 4.0.0
     7 Homepage: <insert the upstream URL, if relevant>
     8
     9 Package: gentoo
    10 Architecture: any
    11 Depends: ${shlibs:Depends}, ${misc:Depends}
    12 Description: <insert up to 60 chars description>
    13  <insert long description, indented with spaces>

    (номера строк добавлены для наглядности)

    Lines 1–7 are the control information for the source package.
    Lines 9–13 are the control information for the binary package.

    В строке 1 содержится название пакета с исходным кодом.

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

    Возможно вы уже заметили, что архив Debian разбит на несколько
    областей: main (свободное ПО), non-free (не совсем свободное ПО)
    и contrib (свободное ПО, зависящее от несвободного ПО). Каждая из
    них делится на разделы, чтобы приближённо разделить пакеты по
    категориям. Так, в admin содержатся программы только для
    администратора, в devel хранятся инструменты разработки ПО, в doc
    содержится документация, в libs содержатся библиотеки, в mail
    содержатся почтовые серверы и программы чтения почты, в net
    содержатся сетевые приложения и службы, в x11 содержатся
    программы для X11, которые не вошли куда-то ещё, и так далее ^
    [28].

    В нашем случае мы должны указать x11 (префикс main/ указывать не
    обязательно — он подставляется по умолчанию).

    В строке 3 указывается насколько важен данный пакет ^[29]:

      * Приоритет optional, обычно, назначается новым пакетам,
        которые не конфликтуют с другими, имеющими приоритет
        required, important или standard.

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

    Так как наш пакет имеет обычный приоритет и не конфликтует с
    другими, мы укажем значение приоритета optional.

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

    Line 5 includes the list of packages required to build your
    package as the Build-Depends field. You can also have the
    Build-Depends-Indep field as an additional line here. ^[30] Some
    packages like gcc and make which are required by the
    build-essential package are implied. If you need to have other
    tools to build your package, you should add them to these fields.
    Multiple entries are separated with commas; read on for the
    explanation of binary package dependencies to find out more about
    the syntax of these lines.

      * Для всех пакетов, упаковываемых с помощью команды dh, в файле
        debian/rules вам потребуется указать debhelper (>=9) в поле
        Build-Depends для соответствия требованиям политики Debian,
        касающимся цели clean.

      * Source packages which have binary packages with Architecture:
        any are rebuilt by the autobuilder. Since this autobuilder
        procedure installs only the packages listed in the
        Build-Depends field before running debian/rules build (see
        Раздел 6.2, «Autobuilder»), the Build-Depends field needs to
        list practically all the required packages, and
        Build-Depends-Indep is rarely used.

      * В пакетах с исходным кодом, в двоичных пакетах которых
        указано Architecture: all, поле Build-Depends-Indep может
        содержать все требуемые пакеты, не перечисленные в
        Build-Depends, для соответствия требованиям политики Debian,
        касающимся цели clean.

    Если вы не знаете, какое из двух полей использовать —
    остановитесь на поле Build-Depends ^[31].

    Для выяснения того, какие пакеты требуются для сборки, выполните
    команду:

    $ dpkg-depcheck -d ./configure

    Для ручного, более точного поиска зависимостей программы /usr/bin
    /foo выполните:

    $ objdump -p /usr/bin/foo | grep NEEDED

    and for each library listed (e.g., libfoo.so.6), execute

    $ dpkg -S libfoo.so.6

    Затем укажите -dev версию каждого пакета в поле Build-Depends.
    Если для этой цели воспользоваться ldd, то вы, помимо прочего,
    узнаете неявные библиотечные зависимости библиотеки и столкнётесь
    с проблемой избыточных сборочных зависимостей.

    Кроме того, пакет gentoo требует для сборки пакеты xlibs-dev,
    libgtk1.2-dev и libglib1.2-dev. Укажите их после пакета
    debhelper.

    В строке 6 указывается версия документа руководства по политике
    Debian, стандартам которого следует данный пакет. Прочитайте его
    при создании пакета.

    В строке 7 можно указать URL домашней страницы программы.

    В строке 9 содержится имя двоичного пакета. Обычно, оно совпадает
    с именем пакета с исходным кодом, но это не является обязательным
    требованием.

    В строке 10 перечислены архитектуры двоичного пакета, для которых
    он может быть скомпилирован. Обычно, здесь указывает одно из
    следующих значений, в зависимости от типа двоичного пакета ^[32]:

      * Architecture: any

          + Генерируемый двоичный пакет зависит от архитектуры,
            обычно определяемой компилируемым языком.
   
      * Architecture: all

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

    Мы не будет менять строку 10, так как программа написана на C.
    Утилита dpkg-gencontrol(1) подставит соответствующее значение
    архитектуры машины, на которой будет скомпилирован пакет с
    исходным кодом.

    Если ваш пакет не зависит от архитектуры (например, это документ,
    сценарий оболочки или Perl), укажите значение all и прочитайте
    Раздел 4.4, «Файл rules», в котором описаны правила использования
    binary-indep вместо binary-arch.

    В строке 11 показана одна из мощнейших сторон пакетной системы
    Debian. Пакеты могут быть связаны друг с другом различными
    способами. Кроме поля Depends за отношения между пакетами
    отвечают Recommends, Suggests, Pre-Depends, Breaks, Conflicts,
    Provides и Replaces.

    Инструменты управления пакетами, обычно, одинаковым образом
    обрабатывают эти связи; если это так, то будет приведён
    комментарий (смотрите dpkg(8), dselect(8), apt(8), aptitude(1) и
    т.д.).

    Вот упрощённое описание связей между пакетами ^[33]:

      * Depends

        Пакет не будет установлен, пока не установлены пакеты, от
        которых он зависит. Используйте этот тип зависимости, если
        ваша программа гарантировано не будет работать (или вызовет
        какие-нибудь серьезные проблемы) при отсутствии какого-то
        пакета.

      * Recommends

        Используйте это поле для пакетов, которые не обязательны, но
        обычно используются с вашей программой. При установке
        программы все интерфейсы управления пакетами предложат
        пользователю установить и рекомендуемые пакеты. Утилиты 
        aptitude и apt-get по умолчанию (которое можно изменить)
        автоматически устанавливают рекомендуемые пакеты вместе с
        пакетом. Утилита dpkg игнорирует это поле.

      * Suggests

        Используйте это поле для пакетов, которые отлично дополнят
        вашу программу, но не требуются для её работы. При установке
        программы интерфейсы управления пакетами, обычно, не
        предлагают пользователю установить такие пакеты. В aptitude
        можно включить автоматическую установку этих предлагаемых
        (suggested) пакетов (по умолчанию не выполняется). Программы 
        dpkg и apt-get игнорируют это поле.

      * Pre-Depends

        В этом поле указываются более важные зависимости, чем в
        Depends. Пакет не будет установлен, если какие-либо пакеты из
        числа таких зависимостей не установлены, либо не правильно
        настроены. Используйте это поле очень осторожно и только
        после обсуждения в рассылке debian-devel@lists.debian.org.
        Ещё лучше — не используйте его вообще :-)

      * Conflicts

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

      * Breaks

        Если пакет будет установлен, то работоспособность всех
        перечисленных пакетов будет нарушена. Чаще всего, в поле
        Breaks указываются пакеты с уточнением версии типа «старее
        чем». Утилиты управления пакетами, обычно, предлагают
        обновить перечисленные пакеты до более новых версий.

      * Provides

        For some types of packages where there are multiple
        alternatives, virtual names have been defined. You can get
        the full list in the virtual-package-names-list.txt.gz file.
        Use this if your program provides a function of an existing
        virtual package.

      * Replaces

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

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

    Для каждого пакета в списке можно указать версии, которых
    касается данная зависимость. Версии указываются в круглых скобках
    после имени пакета и должны состоять из символа сравнения, за
    которым следует номер версии. Допустимыми символами сравнения
    являются: <<, <=, =, >= и >> для «строго раньше», «раньше или
    равно», «в точности равно», «равно или позже» и «строго позже»,
    соответственно. Например:

    Depends: foo (>= 1.2), libbar1 (= 1.3.4)
    Conflicts: baz
    Recommends: libbaz4 (>> 4.0.7)
    Suggests: quux
    Replaces: quux (<< 5), quux-foo (<= 7.6)

    В завершение рассмотрим конструкции ${shlibs:Depends}, $
    {perl:Depends}, ${misc:Depends} и прочие.

    Утилита dh_shlibdeps(1) вычисляет зависимости двоичного пакета от
    общих библиотек. Она генерирует список исполняемых файлов ELF и
    общих библиотек, которые находит для каждого двоичного пакета.
    Этот список подставляется вместо ${shlibs:Depends}.

    Утилита dh_perl(1) вычисляет зависимости Perl. Она генерирует
    список зависимостей от perl или perlapi для каждого двоичного
    пакета. Этот список подставляется вместо ${perl:Depends}.

    Некоторые команды пакета debhelper могут добавлять зависимости к
    вашему генерируемому пакету. Каждая команда генерирует список
    необходимых пакетов для каждого двоичного пакета. Этот список
    подставляется вместо ${misc:Depends}.

    Утилита dh_gencontrol(1) генерирует файл DEBIAN/control для
    каждого двоичного пакета, заменяя ${shlibs:Depends}, $
    {perl:Depends}, ${misc:Depends} и т.д на полученные значения.

    В нашем случае, мы можем оставить поле Depends без изменений и
    добавить после него строчку Suggests: file, так как пакет gentoo
    использует некоторые возможности пакета file.

    В строке 9 указан URL домашней страницы программы. Предположим,
    что это будет http://www.obsession.se/gentoo/.

    В строке 12 содержится краткое описание пакета. Размер экрана у
    большинства пользователей имеет 80 столбцов, поэтому постарайтесь
    ограничить описание шестьюдесятью символами. В нашем случае,
    заполним поле следующим текстом: fully GUI-configurable, two-pane
    X file manager.

    В строке 13 указывается длинное описание. Это должен быть абзац,
    содержащий более полную информацию о пакете. Каждая строка должна
    начинаться с пробела. В тексте не должно быть пустых строк. Если
    пустая строка всё же требуется, то поставьте точку (.) в первом
    столбце. Не выводите более одной пустой строки после длинного
    описания ^[34].

    Давайте вставим поля Vcs-* для указания местонахождения системы
    контроля версий между строкой 6 и 7 ^[35]. Предположим, что пакет
    gentoo в качестве VCS использует сервис Debian Alioth Git по
    адресу git://git.debian.org/git/collab-maint/gentoo.git.

    Вот обновлённый файл control:

     1 Source: gentoo
     2 Section: x11
     3 Priority: optional
     4 Maintainer: Josip Rodin <joy-mg@debian.org>
     5 Build-Depends: debhelper (>=10), xlibs-dev, libgtk1.2-dev, libglib1.2-dev
     6 Standards-Version: 4.0.0
     7 Vcs-Git: https://anonscm.debian.org/git/collab-maint/gentoo.git
     8 Vcs-browser: https://anonscm.debian.org/git/collab-maint/gentoo.git
     9 Homepage: http://www.obsession.se/gentoo/
    10
    11 Package: gentoo
    12 Architecture: any
    13 Depends: ${shlibs:Depends}, ${misc:Depends}
    14 Suggests: file
    15 Description: fully GUI-configurable, two-pane X file manager
    16  gentoo is a two-pane file manager for the X Window System. gentoo lets the
    17  user do (almost) all of the configuration and customizing from within the
    18  program itself. If you still prefer to hand-edit configuration files,
    19  they're fairly easy to work with since they are written in an XML format.
    20  .
    21  gentoo features a fairly complex and powerful file identification system,
    22  coupled to an object-oriented style system, which together give you a lot
    23  of control over how files of different types are displayed and acted upon.
    24  Additionally, over a hundred pixmap images are available for use in file
    25  type descriptions.
    26  .
    29  gentoo was written from scratch in ANSI C, and it utilizes the GTK+ toolkit
    30  for its interface.

    (номера строк добавлены для наглядности)

4.2. Файл copyright

    Этот файл содержит информацию об авторских правах и лицензионное
    соглашение исходной программы. Его содержание определяется в
    руководстве по политике Debian, разделе 12.5 «Информация об
    авторских правах», а формат описан в DEP-5: автоматизируемый
    debian/copyright.

    Шаблон файла copyright можно создать с помощью dh_make. Укажем
    параметр --copyright gpl2, чтобы получить файл шаблона для пакета
    gentoo, выпущенного с лицензией GPL-2.

    You must fill in missing information to complete this file, such
    as the place you got the package from, the actual copyright
    notice, and the license. For certain common free software
    licenses (GNU GPL-1, GNU GPL-2, GNU GPL-3, LGPL-2, LGPL-2.1,
    LGPL-3, GNU FDL-1.2, GNU FDL-1.3, Apache-2.0, 3-Clause BSD,
    CC0-1.0, MPL-1.1, MPL-2.0 or the Artistic license), you can just
    refer to the appropriate file in the /usr/share/common-licenses/
    directory that exists on every Debian system. Otherwise, you must
    include the complete license.

    Вкратце, вот как должен выглядеть файл copyright для пакета
    gentoo:

     1 Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
     2 Upstream-Name: gentoo
     3 Upstream-Contact: Emil Brink <emil@obsession.se>
     4 Source: http://sourceforge.net/projects/gentoo/files/
     5
     6 Files: *
     7 Copyright: 1998-2010 Emil Brink <emil@obsession.se>
     8 License: GPL-2+
     9
    10 Files: icons/*
    11 Copyright: 1998 Johan Hanson <johan@tiq.com>
    12 License: GPL-2+
    13
    14 Files: debian/*
    15 Copyright: 1998-2010 Josip Rodin <joy-mg@debian.org>
    16 License: GPL-2+
    17
    18 License: GPL-2+
    19  This program is free software; you can redistribute it and/or modify
    20  it under the terms of the GNU General Public License as published by
    21  the Free Software Foundation; either version 2 of the License, or
    22  (at your option) any later version.
    23  .
    24  This program is distributed in the hope that it will be useful,
    25  but WITHOUT ANY WARRANTY; without even the implied warranty of
    26  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
    27  GNU General Public License for more details.
    28  .
    29  You should have received a copy of the GNU General Public License along
    30  with this program; if not, write to the Free Software Foundation, Inc.,
    31  51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
    32  .
    33  On Debian systems, the full text of the GNU General Public
    34  License version 2 can be found in the file
    35  '/usr/share/common-licenses/GPL-2'.

    (номера строк добавлены для наглядности)

    Следуйте HOWTO, написанному ftpmaster-ами, и пошлите анонс в
    debian-devel-announce: http://lists.debian.org/
    debian-devel-announce/2006/03/msg00023.html.

4.3. Файл changelog

    Это обязательный файл, его специальный формат описан в
    руководстве по политике Debian, раздел 4.4 «debian/changelog».
    Этот формат используется программой dpkg и другими для получения
    информации о номере версии, редакции, разделе и срочности пакета.

    Для вас он также важен, так как является хорошим местом для
    описания всех изменений, которые вы сделали. Это поможет людям,
    скачавшим ваш пакет, определить, какие выпуски есть у пакета, о
    которых они должны знать. Он будет сохранён как /usr/share/doc/
    gentoo/changelog.Debian.gz в двоичном пакете.

    Программа dh_make создает файл по умолчанию, похожий на этот:

    1  gentoo (0.9.12-1) unstable; urgency=medium
    2
    3   * Initial release. (Closes: #nnnn)  <nnnn is the bug number of your ITP>
    4
    5  -- Josip Rodin <joy-mg@debian.org>  Mon, 22 Mar 2010 00:37:31 +0100
    6

    (номера строк добавлены для наглядности)

    Line 1 is the package name, version, distribution, and urgency.
    The name must match the source package name; distribution should
    be unstable, and urgency should be set to medium unless there is
    any particular reason for other values.

    Lines 3-5 are a log entry, where you document changes made in
    this package revision (not the upstream changes — there is a
    special file for that purpose, created by the upstream authors,
    which you will later install as /usr/share/doc/gentoo/
    changelog.gz). Let's assume your ITP (Intent To Package) bug
    report number was 12345. New lines must be inserted just below
    the uppermost line that begins with * (asterisk). You can do it
    with dch(1). You can edit this manually with a text editor as
    long as you follow the formatting convention used by the dch(1).

    In order to prevent a package being accidentally uploaded before
    completing the package, it is a good idea to change the
    distribution value to an invalid distribution value of
    UNRELEASED.

    Теперь файл будет выглядеть так:

    1  gentoo (0.9.12-1) UNRELEASED; urgency=low
    2
    3   * Initial Release. Closes: #12345
    4   * This is my first Debian package.
    5   * Adjusted the Makefile to fix $(DESTDIR) problems.
    6
    7  -- Josip Rodin <joy-mg@debian.org>  Mon, 22 Mar 2010 00:37:31 +0100
    8

    (номера строк добавлены для наглядности)

    После проверки правильности всех изменений и их описания в
    changelog, измените имя выпуска с UNRELEASED на значение целевого
    дистрибутива unstable (или даже на experimental). ^[36]

    Дополнительную информацию об обновлении файла changelog можно
    найти далее в Глава 8, Обновление пакета.

4.4. Файл rules

    Now we need to take a look at the exact rules that 
    dpkg-buildpackage(1) will use to actually create the package.
    This file is in fact another Makefile, but different from the one
    (s) in the upstream source. Unlike other files in debian, this
    one is marked as executable.

4.4.1. Цели из файла rules

    Файл rules, как и любой Makefile, состоит из нескольких правил,
    каждое из которых описывает цель и способ её достижения ^[37].
    Новое правило начинается с объявления цели в первой колонке.
    Следующие за ним строки начинаются с кода TAB (ASCII 9); в них
    описывается команды достижения цели. Пустые строки и строки,
    начинающиеся с # (решётка), считаются комментариями и
    игнорируются ^[38].

    A rule that you want to execute is invoked by its target name as
    a command line argument. For example, debian/rules build and
    fakeroot make -f debian/rules binary execute rules for build and
    binary targets, respectively.

    Упрощённое объяснение целей:

      * Цель clean служит для удаления всех скомпилированных,
        сгенерированных и бесполезных файлов в дереве сборки
        (требуемая).

      * Цель build служит для сборки исходного кода в
        скомпилированные программы и отформатированные документы в
        дереве сборки (требуемая).

      * Цель build-arch служит для сборки исходного кода в
        независящие от архитектуры скомпилированные программы в
        дереве сборки (требуемая).

      * Цель build-indep служит для сборки исходного кода в
        независящие от архитектуры отформатированные документы в
        дереве сборки (требуемая).

      * Цель install служит для установки файлов в дерево файлов для
        каждого двоичного пакета из каталога debian (необязательная).
        Цели binary* непосредственно зависят от этой цели.

      * Цель binary служит для создания всех двоичных пакетов
        (комбинация целей binary-arch и binary-indep) (требуемая) ^
        [39].

      * Цель binary-arch служит для создания двоичных пакетов,
        зависящих от архитектуры (Architecture: any), в родительском
        каталоге (требуемая) ^[40].

      * Цель binary-indep служит для создания двоичных пакетов,
        независящих от архитектуры (Architecture: all), в
        родительском каталоге (требуемая) ^[41].

      * Цель get-orig-source служит для получения самой новой версии
        пакета с оригинальным исходным кодом с сайта разработчика
        (необязательная).

    Возможное непонимание должно уйти после того, как вы посмотрите
    на содержимое файла rules по умолчанию, который создаётся
    программой dh_make.

4.4.2. Файл rules по умолчанию

    Новая версия dh_make генерирует очень простой, но эффективный
    файл rules по умолчанию, использующий команду dh:

     1 #!/usr/bin/make -f
     2 # See debhelper(7) (uncomment to enable)
     3 # output every command that modifies files on the build system.
     4 #DH_VERBOSE = 1
     5
     6 # see FEATURE AREAS in dpkg-buildflags(1)
     7 #export DEB_BUILD_MAINT_OPTIONS = hardening=+all
     8
     9 # see ENVIRONMENT in dpkg-buildflags(1)
    10 # package maintainers to append CFLAGS
    11 #export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
    12 # package maintainers to append LDFLAGS
    13 #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
    14
    15
    16 %:
    17         dh $@

    (Для наглядности добавлены номера строк и удалены некоторые
    комментарии. В реальном файле rules начальные пробельные символы
    имеют код TAB.)

    Вероятно, вы знакомы с назначением строки 1 по сценариям оболочки
    и Perl. Она указывает операционной системе, что этот файл нужно
    обработать с помощью /usr/bin/make.

    Строку 4 можно раскомментировать, установив значение переменной
    DH_VERBOSE равным 1. При этом команда dh будет выводить команды 
    dh_*, которые она выполняет. Также, здесь вы можете добавить
    строку export DH_OPTIONS=-v. В этом случае каждая команда dh_*
    будет выводить все команды, которые она выполняет. Это помогает
    понять что в действительности происходит в этом простом файле
    rules и при решении проблем. Новая команда dh является основной
    инструментов debhelper и не скрывает своих действий от вас.

    Lines 16 and 17 are where all the work is done with an implicit
    rule using the pattern rule. The percent sign means "any
    targets", which then call a single program, dh, with the target
    name. ^[42] The dh command is a wrapper script that runs
    appropriate sequences of dh_* programs depending on its argument.
    ^[43]

      * При запуске debian/rules clean выполняется команда dh clean,
        которая запускает другие:

        dh_testdir
        dh_auto_clean
        dh_clean

      * debian/rules build runs dh build, which in turn runs the
        following:

        dh_testdir
        dh_auto_configure
        dh_auto_build
        dh_auto_test

      * fakeroot debian/rules binary runs fakeroot dh binary, which
        in turn runs the following^[44]:

        dh_testroot
        dh_prep
        dh_installdirs
        dh_auto_install
        dh_install
        dh_installdocs
        dh_installchangelogs
        dh_installexamples
        dh_installman
        dh_installcatalogs
        dh_installcron
        dh_installdebconf
        dh_installemacsen
        dh_installifupdown
        dh_installinfo
        dh_installinit
        dh_installmenu
        dh_installmime
        dh_installmodules
        dh_installlogcheck
        dh_installlogrotate
        dh_installpam
        dh_installppp
        dh_installudev
        dh_installwm
        dh_installxfonts
        dh_bugfiles
        dh_lintian
        dh_gconf
        dh_icons
        dh_perl
        dh_usrlocal
        dh_link
        dh_compress
        dh_fixperms
        dh_strip
        dh_makeshlibs
        dh_shlibdeps
        dh_installdeb
        dh_gencontrol
        dh_md5sums
        dh_builddeb

      * fakeroot debian/rules binary-arch runs fakeroot dh
        binary-arch, which in turn runs the same sequence as fakeroot
        dh binary but with the -a option appended for each command.

      * fakeroot debian/rules binary-indep runs fakeroot dh
        binary-indep, which in turn runs almost the same sequence as
        fakeroot dh binary but excluding dh_strip, dh_makeshlibs, and
        dh_shlibdeps with the -i option appended for each remaining
        command.

    Назначение команд dh_* практически полностью совпадает с их
    именами ^[45]. Вот несколько наиболее примечательных команд с
    упрощённым описанием, предполагающим использование типичной среды
    сборки на основе Makefile ^[46]:

      * Если существует Makefile с целью distclean, то dh_auto_clean,
        обычно, выполняет следующее ^[47]:

        make distclean

      * Команда dh_auto_configure, обычно, выполняет следующее (если
        существует ./configure; список аргументов сокращён для повышения
        читаемости):

        ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var ...

      * Команда dh_auto_build, обычно, выполняет следующее для первой
        цели в Makefile (если он существует):
   
        make

      * Команда dh_auto_test, обычно, выполняет следующее (если
        существует Makefile с целью test; строка сокращена для повышения
        читаемости) ^[48]:

        make test

      * Команда dh_auto_install, обычно, выполняет следующее (если
        существует Makefile с целью install; строка сокращена для
        повышения читаемости):

        make install \
          DESTDIR=/путь/к/пакету_версия-редакция/debian/пакет

    Цели, которым требуется команда fakeroot, содержат dh_testroot.
    Если вы не притворитесь root с помощью этой команды, то
    выполнение завершится с ошибкой.

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

    Хотя цель install не является обязательной, она всё равно
    поддерживается. Команда fakeroot dh install работает также как
    fakeroot dh binary, но останавливается после dh_fixperms.

4.4.3. Доработка файла rules

    Есть много способов доработать файл rules, созданный новой
    программой dh.

    Работу команды dh $@ можно изменить следующим образом ^[49]:

      * Добавление поддержки команды dh_python2 (лучший выбор для
        Python) ^[50]:

          + В Build-Depends укажите пакет python.

          + Используйте dh $@ --with python2.

          + Это позволяет работать с модулями Python, использующими
            инфраструктуру python.

      * Добавление поддержки команды dh_pysupport (устарела):

          + В Build-Depends укажите пакет python-support.

          + Используйте dh $@ --with pysupport.

          + Это позволяет работать с модулями Python, использующими
            инфраструктуру python-support.

      * Добавление поддержки команды dh_pycentral (устарела):

          + В Build-Depends укажите пакет python-central.

          + Вместо dh $@ используйте dh $@ --with python-central.

          + При этом отключается команда dh_pysupport.

          + Это позволяет работать с модулями Python, использующими
            инфраструктуру python-central.

      * Добавление поддержки команды dh_installtex:

          + В Build-Depends укажите пакет tex-common.

          + Вместо dh $@ используйте dh $@ --with tex.

          + Она регистрирует шрифты в формате Type 1, правила
            переносов или форматы в TeX.

      * Добавление поддержки команд dh_quilt_patch и dh_quilt_unpatch
        :

          + В Build-Depends укажите пакет quilt.

          + Вместо dh $@ используйте dh $@ --with quilt.

          + Эта команда накладывает и откатывает заплаты на исходный
            код из файлов каталога debian/patches для пакетов с
            исходным кодом версии 1.0.

          + Она не требуется, если вы используете пакеты с исходным
            кодом новой версии 3.0 (quilt).

      * Добавление поддержки команды dh_dkms:

          + В Build-Depends укажите пакет dkms.

          + Вместо dh $@ используйте dh $@ --with dkms.

          + Это команда позволяет корректно использовать DKMS для
            пакетов с модулями ядра.

      * Добавление поддержки команд dh_autotools-dev_updateconfig и 
        dh_autotools-dev_restoreconfig:

          + В Build-Depends укажите пакет autotools-dev.

          + Вместо dh $@ используйте dh $@ --with autotools-dev.

          + Эта команда обновляет и восстанавливает config.sub и
            config.guess.

      * Добавление поддержки команд dh_autoreconf и 
        dh_autoreconf_clean:

          + В Build-Depends укажите пакет dh-autoreconf.

          + Вместо dh $@ используйте dh $@ --with autoreconf.

          + Эта команда обновляет файлы GNU Build System и
            восстанавливает их после сборки.

      * Добавление поддержки команды dh_girepository:

          + Укажите пакет gobject-introspection в Build-Depends.

          + Вместо dh $@ используйте dh $@ --with gir.

          + Эта команда вычислит зависимости пакетов, содержащих
            описательные (introspection) данные GObject и сгенерирует
            переменную подстановки ${gir:Depends} для пакетной
            зависимости.

      * Добавление поддержки свойства автодополнения bash:

          + Укажите пакет bash-completion в Build-Depends.

          + Вместо dh $@ используйте dh $@ --with bash-completion.

          + Эта команда установит дополнения bash согласно файлу
            настройки debian/пакет.bash-completion.

    Многие команды dh_*, вызываемые новой командой dh, могут быть
    настроены в соответствующих конфигурационных файлах в каталоге
    debian. Смотрите Глава 5, Другие файлы в каталоге debian/ и
    справочную страницу к каждой команде для настройки этих
    параметров.

    Некоторые команды dh_*, вызванные новой командой dh, могут
    потребовать от вас запустить их с некоторыми аргументами,
    выполнить вместе с ними дополнительные команды или пропустить их.
    В таких случаях надо создать цель override_dh_foo с правилами в
    файле rules только для той команды dh_foo, которую вы собираетесь
    изменить. Она воспринимается как запусти меня вместо той ^[51].

    Заметим, что команды dh_auto_* пытаются делать больше, чем было
    описано (очень) поверхностно ранее, для того, чтобы учесть все
    возможные ситуации. Использование упрощённых эквивалентов команд
    вместо целей override_dh_* — плохая идея (за исключением цели
    override_dh_auto_clean), так как это может привести к удалению
    важных функций debhelper.

    Так, например, если вы хотите хранить системные файлы настройки
    пакета gentoo (использующего Autotools) в каталоге /etc/gentoo
    вместо обычного /etc, то можете переопределить аргумент
    --sysconfig=/etc, заданный по умолчанию, в команде 
    dh_auto_configure, которая передаст его ./configure:

    override_dh_auto_configure:
            dh_auto_configure -- --sysconfig=/etc/gentoo

    The arguments given after -- are appended to the default
    arguments of the auto-executed program to override them. Using
    the dh_auto_configure command is better than directly invoking
    the ./configure command here since it will only override the
    --sysconfig argument and retain any other, benign arguments to
    the ./configure command.

    Если Makefile из исходного кода gentoo требует от вас указания
    build в качестве цели для сборки ^[52], то для этого можно
    создать цель override_dh_auto_build.

    override_dh_auto_build:
            dh_auto_build -- build

    Это гарантирует выполнение $(MAKE) со всеми аргументами по
    умолчанию, заданными в командах dh_auto_build и аргументе build.

    Если Makefile из исходного кода gentoo требует от вас указания
    цели packageclean для очистки пакета Debian, а не distclean или
    clean, то для этого можно создать цель override_dh_auto_clean.

    override_dh_auto_clean:
            $(MAKE) packageclean

    Если Makefile из исходного кода gentoo содержит цель test,
    которую вы не хотите выполнять для процесса сборки пакета Debian,
    то можно использовать пустую цель override_dh_auto_test, чтобы
    пропустить это действие.

    override_dh_auto_test:

    Если в пакете gentoo используется необычный журнальный файл с
    именем FIXES, то по умолчанию dh_installchangelogs не установит
    этот файл. Для его установки укажите команде dh_installchangelogs
    имя FIXES в качестве аргумента ^[53].

    override_dh_installchangelogs:
            dh_installchangelogs FIXES

    При работе с новой командой dh, используйте явные цели,
    перечисленные в Раздел 4.4.1, «Цели из файла rules», остальные же
    (кроме get-orig-source) могут привести к сложностям понимания их
    конечного эффекта. Если возможно, ограничьтесь явно заданными
    целями override_dh_* и полностью независимыми целями.


---------------------------------------------------------------------

    ^[27] Для простоты в этой главе файлы в каталоге debian указаны
    без начального debian/.

    ^[28] Смотрите руководство по политике Debian, раздел 2.4
    «Разделы» и список разделов в sid.

    ^[29] Смотрите руководство по политике Debian, раздел 2.5
    «Приоритеты».

    ^[30] Смотрите руководство по политике Debian, раздел 7.7 «Связи
    между пакетами с исходным кодом и двоичными пакетами —
    Build-Depends, Build-Depends-Indep, Build-Conflicts,
    Build-Conflicts-Indep».

    ^[31] Эта несколько странная ситуация является хорошо
    документированной возможностью, описанной в руководстве по
    политике Debian, сноска 55. Причина не в использовании команды dh
    в файле debian/rules, а в специфике работы dpkg-buildpackage.
    Аналогичный случай встречается в системе автоматической сборки
    Ubuntu.

    ^[32] Подробней об этом смотрите в руководстве по политике
    Debian, раздел 5.6.8 «Architecture».

    ^[33] Смотрите руководство по политике Debian, главу 7
    «Объявление связей между пакетами».

    ^[34] Эти описания составляются на английском языке. Переводы
    описаний выполняются через проект переводов описаний Debian —
    DDTP.

    ^[35] Смотрите справочник разработчика Debian, раздел 6.2.5.
    «Местонахождение системы контроля версий».

    ^[36] Если для выполнения изменения вы используете команду dch
    -r, то убедитесь, что записали файл changelog именно редактором.

    ^[37] You can start learning how to write a Makefile from Debian
    Reference, 12.2. "Make". The full documentation is available as
    http://www.gnu.org/software/make/manual/html_node/index.html or
    as the make-doc package in the non-free archive area.

    ^[38] В руководстве по политике Debian, раздел 4.9 «Главный
    сценарий сборки: debian/rules» этот файл описан подробно.

    ^[39] Эта цель используется dpkg-buildpackage как описано в
    Раздел 6.1, «Полная (пере)сборка».

    ^[40] Эта цель используется dpkg-buildpackage -B, как описано в
    Раздел 6.2, «Autobuilder».

    ^[41] Эта цель используется dpkg-buildpackage -A.

    ^[42] This uses the new debhelper v7+ features. Its design
    concepts are explained in Not Your Grandpa's Debhelper presented
    at DebConf9 by the debhelper upstream. Under lenny, dh_make
    created a much more complicated rules file with explicit rules
    and many dh_* scripts listed for each one, most of which are now
    unnecessary (and show the package's age). The new dh command is
    simpler and frees us from doing the routine work "manually". You
    still have full power to customize the process with override_dh_*
    targets. See Раздел 4.4.3, «Доработка файла rules». It is based
    only on the debhelper package and does not obfuscate the package
    building process as the cdbs package tends to do.

    ^[43] You can verify the actual sequences of dh_* programs
    invoked for a given target without really running them by
    invoking dh target --no-act or debian/rules -- 'target --no-act'.

    ^[44] В следующем примере предполагается, что ваш debian/compat
    содержит значение, равное 9 или более, что позволяет избежать
    автоматического вызова команд поддержки python.

    ^[45] Всю информацию о том, что делают сценарии dh_* и какие они
    имеют параметры, можно найти в их справочных страницах и
    документации к debhelper.

    ^[46] These commands support other build environments, such as
    setup.py, which can be listed by executing dh_auto_build --list
    in a package source directory.

    ^[47] В действительности, в Makefile ищется и выполняется первая
    из доступных целей: distclean, realclean или clean.

    ^[48] В действительности, в Makefile ищется и выполняется первая
    из доступных целей: test или check.

    ^[49] Если с пакетом устанавливается файл /usr/share/perl5/Debian
    /Debhelper/Sequence/своё_имя.pm, то вам нужно активировать его
    функцию доработки командой dh $@ --with своё_имя.

    ^[50] Команда dh_python2 предпочтительнее, чем dh_pysupport или 
    dh_pycentral. Не используйте команду dh_python.

    ^[51] В lenny, если вы хотите изменить поведение сценария dh_*,
    нужно найти соответствующую строку в файле rules правил и
    изменить её.

    ^[52] Программа dh_auto_build без аргументов выполняет правила
    первой цели в Makefile:

    ^[53] Файлы debian/changelog и debian/NEWS всегда устанавливаются
    автоматически. Файл журнала ищется сопоставлением имён файлов,
    приведённых к нижнему регистру и совпадением их с именами
    changelog, changes, changelog.txt и changes.txt.

Глава 5. Другие файлы в каталоге debian/

    The dh_make command had major updates since this old document was
    written. So some parts of this document aren't applicable any
    more.

    The rewrite of this tutorial document with updated contents and
    more practical examples is available as Guide for Debian
    Maintainers. Please use this new tutorial as the primary tutorial
    document.

    The debmake command is used in place of the dh_make command in my
    new Guide for Debian Maintainers.

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

    The dh_make command will create some template configuration files
    under the debian directory. Take a look at all of them.

    Для простоты в этой главе файлы в каталоге debian указаны без
    начального debian/.

    Некоторые шаблоны файлов настройки debhelper не могут быть
    созданы командой dh_make. В таких случаях вам необходимо создать
    их с помощью текстового редактора.

    Если вы хотите активировать некоторые из них, выполните следующие
    действия:

      * переименуйте файлы настройки, используя имя реального
        двоичного пакета;

      * измените содержимое файла шаблона согласно вашим нуждам;

      * удалите файлы шаблонов, в которых нет необходимости;

      * при необходимости, измените файл control (смотрите
        Раздел 4.1, «Файл control»);

      * при необходимости, измените файл rules (смотрите Раздел 4.4,
        «Файл rules»);

    Любые файлы настройки debhelper без префикса имя пакета как,
    например, install, относятся к первому двоичному пакету. Если
    есть несколько двоичных пакетов, их файлы настройки могут быть
    созданы с указанием их имени в имени файла настройки, например,
    пакет-1.install, пакет-2.install и т.д.

5.1. Файл README.Debian

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

    Программа dh_make создала файл, похожий на этот:

    gentoo for Debian
    -----------------
    <possible notes regarding this package - if none, delete this file>
     -- Josip Rodin <joy-mg@debian.org>, Wed, 11 Nov 1998 21:02:14 +0100

    Если вам нечего сюда написать, удалите этот файл. Смотрите 
    dh_installdocs(1).

5.2. Файл compat

    The compat file defines the debhelper compatibility level.
    Currently, you should set it to the debhelper v10 as follows:

    $ echo 10 > debian/compat

    You may use compat level v9 in certain circumstances for
    compatibility with older systems. However, using any level below
    v9 is not recommended and should be avoided for new packages.

5.3. Файл conffiles

    Бывает очень обидно, когда тратишь много времени и усилий на
    настройку программы, а при очередном обновлении все настройки
    исчезают. Debian предлагает решение этой проблемы через механизм
    пометки файлов как настроечных — conffiles ^[54]. Для таких
    файлов при обновлении пакета вам будет задан вопрос, нужно ли
    заменить старые файлы теми, что включены в новый пакет.

    Программа dh_installdeb(1) автоматически помечает все файлы в
    каталоге /etc как файлы conffiles, так что, если у вашей
    программы есть файлы conffiles только там, вам не обязательно
    указывать их в этом файле. Для большинства типов пакетов
    единственное место (и для них так должно быть всегда), в котором
    содержатся файлы conffiles, это /etc и, таким образом, в этом
    файле нет необходимости.

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

    Если программа, которую вы упаковываете, требует от пользователя
    изменить файлы настройки в каталоге /etc, существует два
    популярных способа не отмечать их как conffiles, чтобы подавить
    вопросы со стороны dpkg:

      * Создать символьную ссылку в каталоге /etc, указывающую на
        файл в каталоге /var, генерируемый сценариями
        сопровождающего.

      * Сгенерировать файл в каталоге /etc с помощью сценариев
        сопровождающего.

    Информацию о сценариях сопровождающего смотрите в Раздел 5.18,
    «Файлы {pre|post}{inst|rm}».

5.4. Файлы пакет.cron.*

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

      * пакет.cron.hourly — устанавливается как /etc/cron.hourly/
        пакет; выполняется один раз в час.

      * пакет.cron.daily — устанавливается как /etc/cron.daily/пакет;
        выполняется один раз в день.

      * пакет.cron.weekly — устанавливается как /etc/cron.weekly/
        пакет; выполняется один раз в неделю.

      * пакет.cron.monthly — устанавливается как /etc/cron.monthly/
        пакет; выполняется один раз в месяц.

      * пакет.cron.d — устанавливается как /etc/cron.d/пакет;
        выполняется в любое другое время.

    Большинство этих файлов являются сценариями оболочки, за
    исключением пакет.cron.d, который должен иметь формат crontab(5).

    Для архивирования журнальных файлов никаких файлов cron.*
    задавать ненужно — для этого есть другие средства (смотрите 
    dh_installlogrotate(1) и logrotate(8)).

5.5. Файл dirs

    В этом файле указываются каталоги, которые необходимы для обычной
    установки (make install DESTDIR=..., вызываемая dh_auto_install),
    но которые автоматически не создаются. Обычно, это указывает на
    проблему в Makefile.

    Файлы, указанные в файле install, не нуждаются в предварительном
    создании каталогов. Смотрите Раздел 5.11, «Файл install».

    Для начала лучше попробовать запустить установку и использовать
    этот файл, только если есть проблемы. В начале имён каталогов,
    перечисляемых в файле dirs, косая черта не указывается.

5.6. Файл пакет.doc-base

    Если ваш пакет содержит документацию, отличную от справочных
    страниц или файлов в формате info, то для её регистрации в
    системе вы должны воспользоваться файлом doc-base; это позволит
    пользователю найти её при помощи, например, dhelp(1), dwww(1) или
    doccentral(1).

    Обычно, к таким файлам относятся файлы в форматах HTML, PS и PDF,
    помещаемые в /usr/share/doc/имя_пакета/.

    Вот как выглядит файл gentoo, входящий в пакет gentoo.doc-base:

    Document: gentoo
    Title: Gentoo Manual
    Author: Emil Brink
    Abstract: This manual describes what Gentoo is, and how it can be used.
    Section: File Management
    Format: HTML
    Index: /usr/share/doc/gentoo/html/index.html
    Files: /usr/share/doc/gentoo/html/*.html

    Формат этого файла описан в справочной странице install-docs(8),
    а также в локальной копии руководства Debian по doc-base из
    пакета doc-base.

    Подробная информация по установке дополнительной документации
    приведена в Раздел 3.3, «Установка файлов в их каталоги
    назначения».

5.7. Файл docs

    В этом файле указаны имена файлов документации, которые можно
    установить во временный каталог с помощью dh_installdocs(1).

    По умолчанию будут включены все файлы, имеющиеся в самом верхнем
    каталоге с исходным кодом, а именно BUGS, README*, TODO и т.д.

    Для пакета gentoo также включаются несколько других файлов:

    BUGS
    CONFIG-CHANGES
    CREDITS
    NEWS
    README
    README.gtkrc
    TODO

5.8. Файлы emacsen-*

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

    Они устанавливаются во временный каталог при помощи 
    dh_installemacsen(1).

    Если они вам не нужны, удалите их.

5.9. Файл пакет.examples

    Команда dh_installexamples(1) устанавливает файлы и каталоги,
    указанные в этом файле, как файлы примеров.

5.10. Файлы пакет.init и пакет.default

    Если ваш пакет содержит службу и её необходимо запускать при
    старте системы, вероятнее всего, вы не обратили внимания на мой
    изначальный совет, не так ли? :-)

    Please read dh_installinit(1) dh_installsystemd(1) to provide
    startup script.

    The package.default file will be installed as /etc/default/
    package. This file sets defaults that are sourced by the init
    script. This package.default file is most often used to set some
    default flags or timeouts. If your init script has certain
    configurable features, you can set them in the package.default
    file, instead of in the init script itself.

    Если с оригинальной программой поставляется сценарий
    инициализации, то вы можете использовать и его. Если он вам не
    подходит, то создайте свой в файле с именем пакет.init. Однако,
    если оригинальный сценарий инициализации хорошо написан и
    устанавливается в правильное место, вам всё ещё нужно установить
    символьные ссылки в rc*. Для этого замените dh_installinit в
    файле rules на следующие строки:

    override_dh_installinit:
            dh_installinit --onlyscripts

    Если сценарий инициализации не требуется, удалите эти файлы.

5.11. Файл install

    If there are files that need to be installed into your package
    but your standard make install won't do it, put the filenames and
    destinations into this install file. They are installed by 
    dh_install(1).^[55] You should first check that there is not a
    more specific tool to use. For example, documents should be in
    the docs file and not in this one.

    В файле install для каждого устанавливаемого файла отводится одна
    строка; в ней задаётся имя файла (относительно верхнего каталога
    сборки), потом пробел, потом установочный каталог (относительно
    каталога установки). Например, если при установке не
    устанавливается src/bar, то файл install будет выглядеть так:

    src/bar usr/bin

    В результате после установки пакета в системе появится
    исполняемая команда /usr/bin/bar.

    Также, в файле install можно указывать только имя файла без
    каталога установки, если не менялся относительный путь. Такой
    формат, обычно, используется для большого пакета, в котором
    результат сборки разбивается на несколько двоичных пакетов;
    список устанавливаемых файлов помещается в соответствующий файл
    пакет-1.install, пакет-2.install и т.д.

    Если команда dh_install не находит файлы в текущем каталоге, то
    она ищет их в debian/tmp (или в любом другом месте, указанном в
    --sourcedir).

5.12. Файл пакет.info

    Если у вашего пакета есть страницы в формате info, то их нужно
    устанавливать при помощи dh_installinfo(1), перечислив их в файле
    пакет.info.

5.13. Файл пакет.links

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

5.14. Файлы {пакет.,source/}lintian-overrides

    If lintian reports an erroneous diagnostic for a case where
    Debian policy allows exceptions to some rule, you can use package
    .lintian-overrides or source/lintian-overrides to quieten it.
    Please read the Lintian User's Manual (https://lintian.debian.org
    /manual/index.html) and refrain from abusing this.

    Файл пакет.lintian-overrides предназначен для двоичного пакета и
    устанавливается в usr/share/lintian/overrides/пакет с помощью
    команды dh_lintian.

    Файл source/lintian-overrides предназначен для пакета с исходным
    кодом. Он не устанавливается.

5.15. Файлы manpage.*

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

5.15.1. Файл manpage.1.ex

    Справочные страницы, как правило, пишутся на языке разметки nroff
    (1). Файл шаблона manpage.1.ex также написан на nroff. Смотрите
    справочную страницу man(7), в которой приведено краткое описание
    действий по редактированию подобных файлов.

    Окончательное имя файла справочной страницы должно включать имя
    документируемой программы, поэтому мы переименуем её с manpage на
    gentoo. Имя файла также включает .1 в качестве первого суффикса,
    который означает, что эта справочная страница описывает
    пользовательскую команду. Убедитесь, что используется правильный
    раздел. Вот короткий список разделов справочных страниц:

    
    +---------------------------------------------------------------+
    |Раздел|     Описание     |             Примечания              |
    |------+------------------+-------------------------------------|
    |1     |Пользовательские  |Запускаемые команды или сценарии     |
    |      |команды           |                                     |
    |------+------------------+-------------------------------------|
    |2     |Системные вызовы  |Функции, предоставляемые ядром       |
    |------+------------------+-------------------------------------|
    |3     |Библиотечные      |Функции, предоставляемые системными  |
    |      |вызовы            |библиотеками                         |
    |------+------------------+-------------------------------------|
    |4     |Специальные файлы |Обычно находятся в каталоге /dev     |
    |------+------------------+-------------------------------------|
    |5     |Форматы файлов    |Например, формат /etc/passwd         |
    |------+------------------+-------------------------------------|
    |6     |Игры              |Игры и другие несерьёзные программы  |
    |------+------------------+-------------------------------------|
    |7     |Пакеты макросов   |Например, макросы man                |
    |------+------------------+-------------------------------------|
    |8     |Системное         |Программы, обычно запускаемые только |
    |      |администрирование |суперпользователем                   |
    |------+------------------+-------------------------------------|
    |9     |Функции ядра      |Нестандартные вызовы и внутреннее    |
    |      |                  |устройство                           |
    +---------------------------------------------------------------+

    Таким образом, справочная страница для gentoo должна называться
    gentoo.1. Если в исходном коде нет справочной страницы gentoo.1,
    то её нужно создать путём переименовывания шаблона manpage.1.ex в
    gentoo.1 и затем изменить его, используя информацию из примера и
    документации к исходной программе.

    Также, вы можете использовать команду help2man для генерации
    справочной страницы, которая для создания использует результат
    запуска команды с параметрами --help и --version ^[56].

5.15.2. Файл manpage.sgml.ex

    Если вы предпочитаете использовать SGML вместо nroff, то можете
    использовать шаблон manpage.sgml.ex. Для этого необходимо:

      * переименовать файл в gentoo.sgml;

      * установить пакет docbook-to-man;

      * в файл control добавить docbook-to-man в строку
        Build-Depends;

      * добавить цель override_dh_auto_build в файл rules:

        override_dh_auto_build:
                docbook-to-man debian/gentoo.sgml > debian/gentoo.1
                dh_auto_build

5.15.3. Файл manpage.xml.ex

    Если вы предпочитаете использовать XML вместо SGML, то можете
    использовать шаблон manpage.xml.ex. Для этого необходимо:

      * переименовать исходный файл в gentoo.1.xml;

      * установить пакет docbook-xsl и обработчик XSLT (рекомендуется
        xsltproc);

      * в файл control добавить пакеты docbook-xsl, docbook-xml и
        xsltproc в строку Build-Depends;

      * добавить цель override_dh_auto_build в файл rules:
   
        override_dh_auto_build:
                xsltproc --nonet \
                 --param make.year.ranges 1 \
                 --param make.single.year.ranges 1 \
                 --param man.charmap.use.subset 0 \
                 -o debian/ \
        http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl\
                debian/gentoo.1.xml
                dh_auto_build

5.16. Файл пакет.manpages

    Если ваш пакет содержит справочные страницы, то их следует
    устанавливать с помощью dh_installman(1), перечислив в файле
    пакет.manpages.

    Чтобы установить справочную страницу doc/gentoo.1 для пакета
    gentoo, создайте следующий файл gentoo.manpages:

    docs/gentoo.1

5.17. Файл NEWS

    Этот файл устанавливается командой dh_installchangelogs(1).

5.18. Файлы {pre|post}{inst|rm}

    Файлы postinst, preinst, postrm и prerm ^[57] называются
    сценариями сопровождающего. Эти сценарии находятся в управляющей
    области пакета и запускаются программой dpkg при установке,
    обновлении или удалении пакета.

    Как начинающему сопровождающему вам следует избегать ручной
    правки сценариев сопровождающего, так как они имеют тенденцию
    усложняться. Более подробную информацию смотрите в руководстве по
    политике Debian, глава 6 «Сценарии сопровождающего пакета и
    процесс установки», и взгляните на файлы примеров,
    предоставляемые dh_make.

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

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

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

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

    Сценарии сопровождающего являются сильной стороной Debian, из-за
    них люди выбирают Debian. Вы должны быть очень осторожны, чтобы
    не превратить их в источник раздражения.

5.19. Файл пакет.symbols

    Packaging of a library is not easy for a novice maintainer and
    should be avoided. Having said it, if your package has libraries,
    you should have debian/package.symbols files. See Раздел A.2,
    «Управление debian/пакет.symbols».

5.20. Файл TODO

    Этот файл устанавливается командой dh_installdocs(1).

5.21. Файл watch

    The watch file format is documented in the uscan(1) manpage. The
    watch file configures the uscan program (in the devscripts
    package) to watch the site where you originally got the source.
    This is also used by the Debian Package Tracker service.

    Вот его содержимое:

    # управляющий файл watch для uscan
    version=3
    http://sf.net/gentoo/gentoo-(.+)\.tar\.gz debian uupdate

    Обычно, с указанного в файле watch URL http://sf.net/gentoo
    скачивается страница и в ней ищутся ссылки вида <a href=...>.
    Базовое имя (часть за последним /) каждой найденной ссылки
    сравнивается с шаблоном регулярного выражения Perl (смотрите 
    perlre(1)) gentoo-(.+)\.tar\.gz. Из совпавших файлов загружается
    файл с наибольшим номером версии и запускается программа uupdate,
    которая создаёт из них обновлённое дерево исходного кода.

    Although this is true for other sites, the SourceForge download
    service at http://sf.net is an exception. When the watch file has
    a URL matching the Perl regexp ^http://sf\.net/, the uscan
    program replaces it with http://qa.debian.org/watch/sf.php/ and
    then applies this rule. The URL redirector service at http://
    qa.debian.org/ is designed to offer a stable redirect service to
    the desired file for any watch pattern of the form http://sf.net/
    project/tar-name-(.+)\.tar\.gz. This solves issues related to
    periodically changing SourceForge URLs.

    Если автор программы подписывает tarball ключом, то рекомендуется
    проверять его подпись с помощью параметра pgpsigurlmangle как
    описано в uscan(1).

5.22. Файл source/format

    В файле debian/source/format должна содержаться единственная
    строка, указывающая на желаемый формат пакета с исходным кодом
    (полный список смотрите в dpkg-source(1)). После squeeze он
    должен содержать либо:

      * 3.0 (native) — для родных пакетов Debian;
   
      * 3.0 (quilt) — для всего остального.

    В новом формате пакетов с исходным кодом 3.0 (quilt) изменения
    записываются в виде серии заплат quilt в каталог debian/patches.
    Эти изменения автоматически накладываются в ходе распаковки
    пакета исходного кода ^[58]. Изменения Debian хранятся в архиве
    debian.tar.gz, содержащем все файлы из каталога debian. Новый
    формат позволяет сопровождающему включать двоичные файлы, такие
    как значки в формате PNG, без дополнительных ухищрений ^[59].

    Когда программа dpkg-source распаковывает пакет с исходным кодом
    в формате 3.0 (quilt), она автоматически накладывает все заплаты,
    перечисленные в файле debian/patches/series. Вы можете избежать
    наложения заплат в конце распаковки, указав параметр
    --skip-patches.

5.23. Файл source/local-options

    When you want to manage Debian packaging activities under a VCS,
    you typically create one branch (e.g., upstream) tracking the
    upstream source and another branch (e.g., typically master for
    Git) tracking the Debian package. For the latter, you usually
    want to have unpatched upstream source with your debian/* files
    for the Debian packaging to ease merging of the new upstream
    source.

    После того, как вы собрали пакет, исходный код, обычно, остаётся
    изменённым. Вам необходимо вручную убрать изменения, внесённые
    заплатами, с помощью запуска dquilt pop -a перед сохранением в
    ветку master. Вы можете автоматизировать это, добавив
    дополнительный файл debian/source/local-options, содержащий
    unapply-patches. Этот файл не включается в генерируемый пакет с
    исходным кодом и изменяет только поведение локальной сборки.
    Также, он может содержать abort-on-upstream-changes (смотрите 
    dpkg-source(1)).

    unapply-patches
    abort-on-upstream-changes

5.24. Файл source/options

    Автоматически генерируемые файлы в дереве исходного кода могут
    немного раздражать при пакетировании, так как из-за них
    генерируются бесполезные большие файлы заплат. Для решения этой
    проблемы есть специальные модули, такие как dh_autoreconf,
    описанные в Раздел 4.4.3, «Доработка файла rules».

    При создании пакета с исходным кодом вы можете указать регулярное
    выражение Perl в параметре --extend-diff-ignore для dpkg-source
    (1), чтобы игнорировать изменения в автоматически генерируемых
    файлах.

    Общим решением этой проблемы с автоматически создаваемыми файлами
    является сохранение аргумента dpkg-source в файле пакета с
    исходным кодом source/options. Благодаря следующим настройкам в
    файлы заплат не будут включены config.sub, config.guess и
    Makefile.

    extend-diff-ignore = "(^|/)(config\.sub|config\.guess|Makefile)$"

5.25. Файлы patches/*

    При использовании старого формата пакета с исходным кодом 1.0
    создавался один большой файл diff.gz, который содержал файлы
    сопровождения в debian и заплаты к исходному коду. Такой пакет
    немного громоздок для проверки и понимания каждого изменения
    дерева исходного кода. Это не так уж хорошо.

    В новом формате 3.0 (quilt) заплаты хранятся в файлах debian/
    patches/*, для создания которых применяется команда quilt. Эти
    заплаты и другие данные пакета — всё содержимое каталога debian —
    упаковывается в файл debian.tar.gz. Так как команда dpkg-source
    может работать с данными quilt в формате 3.0 (quilt) без пакета
    quilt, то его не нужно включать в зависимости Build-Depends ^[60]
    .

    Работа с командой quilt описана в quilt(1). Она записывает
    изменения исходного кода в виде набора заплат -p1 в каталоге
    debian/patches, а дерево исходного кода вне каталога debian
    остаётся нетронутым. Порядок применения этих заплат указывается в
    файле debian/patches/series. Вы можете легко наложить (=push),
    откатить (=pop) или обновить заплаты ^[61].

    В Глава 3, Изменение исходного кода мы создали 3 заплаты в debian
    /patches.

    Поскольку заплаты Debian расположены в debian/patches, убедитесь,
    что программа dquilt настроена правильно, как было описано в
    Раздел 3.1, «Настройка quilt».

    Позднее, когда кто-то (включая вас самих) предоставляет заплату
    foo.patch к исходному коду, изменить пакет исходного кода 3.0
    (quilt) очень просто:

    $ dpkg-source -x gentoo_0.9.12.dsc
    $ cd gentoo-0.9.12
    $ dquilt import ../foo.patch
    $ dquilt push
    $ dquilt refresh
    $ dquilt header -e
    ... описание заплаты

    Заплаты, хранимые в новом формате исходного кода 3.0 (quilt),
    должны быть без ненужного мусора. Вы должны убедиться в этом,
    запустив: dquilt pop -a; while dquilt push; do dquilt refresh;
    done.


---------------------------------------------------------------------

    ^[54] Смотрите dpkg(1) и руководство по политике Debian, раздел
    «D.2.5 Conffiles».

    ^[55] Этот файл заменяет устаревшую команду dh_movefiles(1),
    которая настраивается с помощью файла files.

    ^[56] Заметим, что в шаблоне справочной страницы из help2man
    утверждается, что более подробная документация приведена в
    справочной системе info. Если для команды нет страницы info, то
    вам нужно изменить справочную страницу, созданную командой 
    help2man.

    ^[57] Несмотря на то, что здесь используется сокращённое
    выражение bash для обозначения этих файлов в виде {pre|post}{inst
    |rm}, в сценариях сопровождающего рекомендуется использовать
    только синтаксис POSIX для лучшей совместимости с системной
    оболочкой dash.

    ^[58] Обзор перехода на новые форматы пакетов 3.0 (quilt) и 3.0
    (native) с исходным кодом смотрите в DebSrc3.0.

    ^[59] Фактически, новый формат также позволяет использовать
    несколько tar-архивов исходной программы и дополнительные методы
    сжатия. Описание этого выходит за рамки данного документа.

    ^[60] Для управления набором заплат в пакетировании Debian были
    предложены и применяется несколько методов. Система quilt —
    предпочтительная система сопровождения. Также есть dpatch, dbs, 
    cdbs и другие. Многие из них хранят заплаты в файлах debian/
    patches/*.

    ^[61] Если вы просите поручителя загрузить ваш пакет, такое
    чёткое разделение и документирование ваших изменений очень важно
    для ускорения проверки пакета поручителем.

Глава 6. Сборка пакета

    The rewrite of this tutorial document with updated contents and
    more practical examples is available as Guide for Debian
    Maintainers. Please use this new tutorial as the primary tutorial
    document.

    Теперь мы готовы собрать пакет.

6.1. Полная (пере)сборка

    Для полной (пере)сборки пакета, необходимо убедиться в установке
    следующего:

      * пакета build-essential,

      * пакетов, перечисленных в поле Build-Depends (смотрите
        Раздел 4.1, «Файл control») и

      * пакетов, перечисленных в поле Build-Depends-indep (смотрите
        Раздел 4.1, «Файл control»).

    Затем выполните следующую команду в каталоге с исходным кодом:

    $ dpkg-buildpackage -us -uc

    Она сделает всё, что необходимо для создания всех двоичных
    пакетов и пакета с исходным кодом. Она выполняет:

      * очистку дерева исходного кода (debian/rules clean)

      * сборку пакета с исходным кодом (dpkg-source -b)

      * сборку программы (debian/rules build)
   
      * сборку двоичных пакетов (fakeroot debian/rules binary)

      * создаёт файл .dsc

      * создаёт файл .changes с помощью dpkg-genchanges

    If the build result is satisfactory, sign the .dsc and .changes
    files with your private GPG key using the debsign command. You
    need to enter your secret pass phrase, twice. ^[62]

    Для неродного пакета Debian, например, gentoo, после сборки
    пакетов вы увидите следующие файлы в родительском каталоге (~/
    gentoo):

      * gentoo_0.9.12.orig.tar.gz

        This is the original upstream source code tarball, merely
        renamed to the above so that it adheres to the Debian
        standard. Note that this was created initially by the command
        dh_make -f ../gentoo-0.9.12.tar.gz.

      * gentoo_0.9.12-1.dsc

        Этот файл содержит информацию о содержимом исходного кода. Он
        файл генерируется из вашего файла control и используется при
        распаковке пакета с исходным кодом с помощью dpkg-source(1).

      * gentoo_0.9.12-1.debian.tar.gz

        В этом сжатом архиве tar находится содержимое вашего каталога
        debian. Все дополнения, вносимые вами в исходный код,
        хранятся в виде заплат quilt в каталоге debian/patches.

        Если кто-либо захочет пересоздать ваш пакет с нуля, они легко
        смогут сделать это, используя перечисленные выше три файла.
        Процедура извлечения тривиальна: просто скопируйте
        куда-нибудь три файла и выполните dpkg-source -x
        gentoo_0.9.12-1.dsc ^[63].

      * gentoo_0.9.12-1_i386.deb

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

      * gentoo_0.9.12-1_i386.changes

        В этом файле описываются все изменения, сделанные в данной
        редакции пакета, и он используется программами поддержки
        FTP-архива Debian для внесения пакетов (как двоичных, так и с
        исходным кодом) в архив. Он частично генерируется из файлов
        changelog и .dsc.

        По мере того, как вы будете работать над пакетом, будет
        меняться его поведение и будет добавляться новая
        функциональность. Люди, загружающие ваш пакет, могут
        посмотреть этот файл и сразу понять, что было изменено.
        Программы поддержки архива Debian будут также отправлять
        содержимое этого файла в список рассылки
        debian-devel-changes@lists.debian.org.

    The gentoo_0.9.12-1.dsc and gentoo_0.9.12-1_i386.changes files
    must be signed using the debsign command with your private GPG
    key in the ~/.gnupg/ directory, before uploading them to the
    Debian FTP archive. The GPG signature provides the proof that
    these files are really yours, using your public GPG key.

    The debsign command can be made to sign with your specified
    secret GPG key ID (good for sponsoring packages) with the
    following in the ~/.devscripts file:

    DEBSIGN_KEYID=ID_ключа_GPG

    Длинные строки цифр в файлах .dsc и .changes — это контрольные
    суммы SHA1/SHA256 упомянутых файлов. Человек, загружающий ваши
    файлы, может проверить их с помощью sha1sum(1) или sha256sum(1)
    и, если числа не совпадают, он поймёт, что файл был повреждён или
    подделан.

6.2. Autobuilder

    Debian поддерживает много переносов с помощью сети autobuilder, в
    которой работает служба buildd на компьютерах различных
    архитектур. Хотя вам и не придётся этим заниматься, но всё же
    следует узнать, что будет происходить с вашими пакетами.
    Рассмотрим в общих чертах как ваш пакет пересобирается для
    различных архитектур ^[64].

    Для пакетов с Architecture: any система autobuilder выполняет
    пересборку. Она убеждается, что установлен

      * пакет build-essential и
   
      * пакеты, перечисленные в поле Build-Depends (смотрите
        Раздел 4.1, «Файл control»).

    Затем в каталоге с исходным кодом вызывается команда

    $ dpkg-buildpackage -B

    Она делает всё необходимое для сборки пакетов для данной
    архитектуры. А именно:

      * очистку дерева исходного кода (debian/rules clean)

      * сборку программы (debian/rules build)

      * сборку архитектурно-зависимых двоичных пакетов (fakeroot
        debian/rules binary-arch)

      * подпись файла исходного кода .dsc с помощью gpg

      * создание и подпись загружаемого файла .changes с помощью 
        dpkg-genchanges и gpg

    Так ваш пакет собирается для различных архитектур.

    Хотя пакеты, перечисленные в поле Build-Depends-indep, должны
    быть установлены при ручном пакетировании (смотрите Раздел 6.1,
    «Полная (пере)сборка»), их не нужно устанавливать при
    использовании системы autobuilder, так как она занимается
    исключительно архитектурно-зависимыми двоичными пакетами ^[65].
    Это различие между обычным пакетированием и использованием
    autobuilder определяет, где должны быть перечислены необходимые
    пакеты: в поле Build-Depends или Build-Depends-indep файла debian
    /control (смотрите Раздел 4.1, «Файл control»).

6.3. Команда debuild

    Для автоматизации действий по сборки с помощью dpkg-buildpackage
    можно использовать команду debuild. Смотрите debuild(1).

    The debuild command executes the lintian command to make a static
    check after building the Debian package. The lintian command can
    be customized with the following in the ~/.devscripts file:

    DEBUILD_DPKG_BUILDPACKAGE_OPTS="-us -uc -I -i"
    DEBUILD_LINTIAN_OPTS="-i -I --show-overrides"

    Для очистки каталога исходного кода и пересборки пакета
    выполните:

    $ debuild

    Для очистки древа исходного кода выполните:

    $ debuild -- clean

6.4. Пакет pbuilder

    В чистой среде сборки (chroot) для проверки пакетных зависимостей
    очень полезен пакет pbuilder ^[66]. Он поможет убедиться в
    чистоте сборки под управлением auto-builder из sid для различных
    архитектур и избежать опасной ошибки FTBFS (ошибка сборки из
    исходного кода), которая всегда относится к категории RC
    (критична для данного выпуска) ^[67].

    Давайте настроим пакет pbuilder следующим образом:

      * дадим пользователю право записи в каталог /var/cache/pbuilder
        /result

      * создадим каталог для размещения сценариев, например, /var/
        cache/pbuilder/hooks, доступный пользователю для записи.
   
      * добавим в файл ~/.pbuilderrc или в /etc/pbuilderrc следующие
        строки:

        AUTO_DEBSIGN=${AUTO_DEBSIGN:-no}
        HOOKDIR=/var/cache/pbuilder/hooks

    Для начальной инициализации локальной системы chroot пакета
    pbuilder выполним:

    $ sudo pbuilder create

    Если у вас имеется готовый пакет исходного кода, то в каталоге,
    где расположены файлы foo.orig.tar.gz, foo.debian.tar.gz и foo
    .dsc, для обновления локальной системы chroot пакета pbuilder и
    сборки соответствующих двоичных пакетов выполните следующие
    команды:

    $ sudo pbuilder --update
    $ sudo pbuilder --build foo_версия.dsc

    Только что собранные пакеты без подписи GPG будут помещены в
    каталог /var/cache/pbuilder/result/, их владельцем будет обычный
    пользователь (не суперпользователь).

    Подписи GPG для файлов .dsc и .changes можно сгенерировать
    следующим образом:

    $ cd /var/cache/pbuilder/result/
    $ debsign foo_версия_архитектура.changes

    Если у вас есть обновлённое древо исходного кода, но нет
    собранных пакетов с исходным кодом, выполните в каталоге, где
    размещён подкаталог debian, другие команды:

    $ sudo pbuilder --update
    $ pdebuild

    Вы можете войти внутрь окружения chroot и настроить его командой
    pbuilder --login --save-after-login. Изменения будут сохранены,
    когда вы покинете оболочку, нажав ^D (Control-D).

    Последняя версия команды lintian может быть вызвана в окружении
    chroot, используя сценарий /var/cache/pbuilder/hooks//B90lintian,
    настроенный следующим образом ^[68]:

    #!/bin/sh
    set -e
    install_packages() {
            apt-get -y --allow-downgrades install "$@"
            }
    install_packages lintian
    echo "+++ lintian output +++"
    su -c "lintian -i -I --show-overrides /tmp/buildd/*.changes" - pbuilder
    # use this version if you don't want lintian to fail the build
    #su -c "lintian -i -I --show-overrides /tmp/buildd/*.changes; :" - pbuilder
    echo "+++ end of lintian output +++"

    Для правильной сборки пакета для sid вам потребуется самое свежее
    окружение этой ветви, однако миграция на sid всей системы может
    быть нежелательна. Пакет pbuilder поможет вам в этой ситуации.

    You may need to update your stable packages after their release
    for stable-proposed-updates, stable/updates, etc. ^[69] For such
    occasions, the fact that you may be running a sid system is not a
    good enough excuse for failing to update them promptly. The
    pbuilder package can help you to access environments of almost
    any Debian derivative distribution of the same architecture.

    Смотрите http://www.netfort.gr.jp/~dancer/software/pbuilder.html,
    pdebuild(1), pbuilderrc(5) и pbuilder(8).

6.5. git-buildpackage command and similar

    Если автор программы применяет систему управления кодом ^[70], то
    и вы можете использовать её возможности. Это упрощает слияние и
    выборку заплат для исходного кода. Для каждой VCS существуют
    специализированные инструменты, позволяющие производить сборку
    пакетов Debian:

      * git-buildpackage: инструменты для пакетирования в
        репозиториях Git.

      * svn-buildpackage: вспомогательные программы для сопровождения
        пакетов Debian в Subversion.

      * cvs-buildpackage: набор сценариев для пакетирования в CVS.

    Среди разработчиков Debian становится популярным использовать
    git-buildpackage для управления пакетами Debian на сервере Git
    alioth.debian.org. ^[71] В этот пакет включено много команд для 
    автоматизации процесса упаковки:

      * gbp-import-dsc(1): import a previous Debian package to a Git
        repository.

      * gbp-import-orig(1): import a new upstream tar to a Git
        repository.

      * gbp-dch(1): generate the Debian changelog from Git commit
        messages.

      * git-buildpackage(1): сборка пакетов Debian из репозитория
        Git.

      * git-pbuilder(1): сборка пакетов Debian из репозитория Git с
        помощью pbuilder/cowbuilder.

    Для ведения пакетирования в этих командах используются 3 ветви:

      * main — дерево родных пакетов Debian.

      * upstream — дерево авторского исходного кода.

      * pristine-tar для авторского tar, создаваемый при
        использовании параметра --pristine-tar.^[72]

    Для настройки git-buildpackage используйте файл ~/.gbp.conf.
    Смотрите gbp.conf(5). ^[73]

6.6. Быстрая пересборка

    При работе над большим пакетом, возможно, вы не захотите каждый
    раз полностью пересобирать его из исходного кода при изменении
    настроек в файле debian/rules. Исключительно для тестовых целей
    вы можете создать deb-файл без пересборки кода следующим образом
    ^[74]:

    $ fakeroot debian/rules binary

    Или просто выполните для выяснения возможна ли сборка пакета:

    $ fakeroot debian/rules build

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

6.7. Иерархия команд

    Вот краткая сводка команд, которые объединяются в единую систему
    для сборки пакетов. Есть много способов сделать одно и тоже.

      * debian/rules = сценарий сопровождающего для сборки пакета

      * dpkg-buildpackage = ключевой инструмент сборки пакета

      * debuild = dpkg-buildpackage + lintian (сборка при проверенных
        переменных окружение)

      * pbuilder = ключевой инструмент chroot-окружения Debian

      * pdebuild = pbuilder + dpkg-buildpackage (сборка в chroot)

      * cowbuilder = ускорение выполнения pbuilder

      * git-pbuilder = простой синтаксис командной строки для 
        pdebuild (используется в gbp buildpackge)

      * gbp = управление исходным кодом Debian в репозитории git

      * gbp buildpackge = pbuilder + dpkg-buildpackage + gbp

    Хотя высокоуровневые команды, такие как gbp buildpackge и 
    pbuilder, предоставляют замечательную среду сборки пакета,
    необходимо понимать какие нижележащие команды, такие как debian/
    rules и dpkg-buildpackage, в них используются.


---------------------------------------------------------------------

    ^[62] Для подключения к доверенному веб (web of trust) этот ключ
    GPG должен быть подписан разработчиком Debian и должен быть
    зарегистрирован в связке ключей Debian. Это позволяет закачивать
    пакеты для приёма в архивы Debian. Смотрите Создание нового ключа
    GPG и вики Debian по подписыванию ключами.

    ^[63] Вы можете избежать наложения заплат quilt в формате
    исходного кода 3.0 (quilt) в конце извлечения, указав параметр
    --skip-patches. Или же вы можете выполнить quilt pop -a после
    обычной распаковки.

    ^[64] На самом деле, работа системы autobuilder гораздо сложнее,
    однако её детальное описание не для этого документа.

    ^[65] В отличие от пакета pbuilder,окружение chroot из пакета
    sbuild, который используется системой autobuilder, не требует
    минимальной системы и допускает наличие установленных пакетов, не
    являющихся необходимыми.

    ^[66] Так как пакет pbuilder всё ещё развивается, за
    подробностями настройки обратитесь к его официальной
    документации.

    ^[67] Более полная информация по автоматической сборке пакетов
    Debian приведена в http://buildd.debian.org/.

    ^[68] Здесь предполагается, что HOOKDIR=/var/cache/pbuilder/
    hooks. Примеры вызываемых (hook) сценариев можно найти в каталоге
    /usr/share/doc/pbuilder/examples.

    ^[69] Есть некоторые ограничения для такого обновления пакета из
    stable.

    ^[70] Смотрите Системы управления версиями.

    ^[71] В вики Debian Alioth описано как использовать службу
    alioth.debian.org.

    ^[72] The --pristine-tar option invokes the pristine-tar command,
    which can regenerate an exact copy of a pristine upstream tarball
    using only a small binary delta file and the contents of the
    tarball that are typically kept in an upstream branch in the VCS.

    ^[73] Несколько веб-ресурсов для опытных пользователей:

      * Сборка пакетов Debian с помощью git-buildpackage (/usr/share/
        doc/git-buildpackage/manual-html/gbp.html)

      * Пакеты debian в git

      * Использование Git для пакетирования Debian

      * git-dpm: пакеты Debian в Git

    ^[74] Environment variables that are normally configured to
    proper values are not set by this method. Never create real
    packages to be uploaded using this quick method.

Глава 7. Проверка пакета на наличие ошибок

    The rewrite of this tutorial document with updated contents and
    more practical examples is available as Guide for Debian
    Maintainers. Please use this new tutorial as the primary tutorial
    document.

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

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

7.1. Подозрительные изменения

    Если вы обнаружите новые автоматически сгенерированные файлы
    заплат debian-changes-* в каталоге debian/patches после сборки
    своего неродного пакета Debian в формате 3.0 (quilt), то,
    вероятнее всего, вы неумышленно изменили какие-то файлы или это
    сделал авторский сценарий сборки. Если это ваша ошибка, исправьте
    её. Если это сценарий, то исправьте источник ошибки с помощью 
    dh-autoreconf, как это описано в Раздел 4.4.3, «Доработка файла
    rules», или обойдите её с помощью source/options, который описан
    в Раздел 5.24, «Файл source/options».

7.2. Проверка установки пакета

    You must test your package for whether it installs without
    problems. The debi(1) command helps you to test installing all
    the generated binary packages.

    $ sudo debi gentoo_0.9.12-1_i386.changes

    To prevent installation problems on different systems, you must
    make sure that there are no filenames conflicting with other
    existing packages, using the Contents-i386 file downloaded from
    the Debian archive. The apt-file command may be handy for this
    task. If there are collisions, please take action to avoid this
    real problem, whether by renaming the file, moving a common file
    to a separate package that multiple packages can depend on, using
    the alternatives mechanism (see update-alternatives(1)) in
    coordination with the maintainers of other affected packages, or
    declaring a Conflicts relationship in the debian/control file.

7.3. Проверка сценариев сопровождающего пакета

    Все сценарии сопровождающего (preinst, prerm, postinst и postrm)
    сложны в написании, если только для их автоматической генерации
    не применялись программы из пакета debhelper. Поэтому не
    пользуйтесь этими сценариями, если вы начинающий сопровождающий
    (смотрите Раздел 5.18, «Файлы {pre|post}{inst|rm}»).

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

    $ sudo dpkg -r gentoo
    $ sudo dpkg -P gentoo
    $ sudo dpkg -i gentoo_версия-редакция_i386.deb

    Следует выполнить следующие шаги:

      * установите предыдущую версию (если необходимо)

      * обновите пакет с предыдущей версии

      * откатитесь на предыдущую версию (по желанию)

      * вычистите пакет
   
      * установите новый пакет

      * удалите его

      * установите опять

      * вычистите пакет

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

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

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

7.4. Использование lintian

    Запустите lintian(1), передав ей параметром файл .changes.
    Команда lintian выполняет множество тестовых сценариев,
    проверяющих наличие типичных ошибок пакетирования ^[75].

    $ lintian -i -I --show-overrides gentoo_0.9.12-1_i386.changes

    Разумеется, следует заменить имя файла .changes на то, которое
    было сгенерировано для вашего пакета. В результатах команды 
    lintian используются следующие метки:

      * E: — ошибка; нарушение политики или ошибка пакетирования.

      * W: — предупреждение; возможное нарушение политики или ошибка
        пакетирования.

      * I: — для информации; сведения о некоторых аспектах
        пакетирования.

      * N: — замечание; уточнение, помогающее при отладке.

      * O: — скрытые сообщения; информация, скрываемая на основе
        файла lintian-overrides, но показываемая при указании
        параметра --show-overrides.

    Если вы видите предупреждения — исправьте пакет, чтобы их не было
    или убедитесь, что это нормально. Если предупреждения излишни —
    настройте файл lintian-overrides, как описано в Раздел 5.14,
    «Файлы {пакет.,source/}lintian-overrides».

    Заметим, что команда debuild(1) или pdebuild(1) позволяет собрать
    пакет с помощью dpkg-buildpackage и сразу проверить его lintian.

7.5. Команда debc

    Вы можете просмотреть список файлов в двоичном пакете Debian с
    помощью команды debc(1).

    $ debc пакет.changes

7.6. Команда debdiff

    Вы можете сравнить содержимое файлов двух пакетов исходного кода
    Debian с помощью команды debdiff(1).

    $ debdiff старый-пакет.dsc новый-пакет.dsc

    Также с помощью команды debdiff(1) вы можете сравнить списки
    файлов двух двоичных пакетов Debian.

    $ debdiff старый-пакет.changes новый-пакет.changes

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

7.7. Команда interdiff

    Команда interdiff(1) позволяет сравнить два файла diff.gz. Это
    полезно для проверки отсутствия сделанных сопровождающим
    нечаянных правок исходного кода при обновлении пакетов в старом
    формате 1.0.

    $ interdiff -z старый-пакет.diff.gz новый-пакет.diff.gz

    В новой версии формата пакетов с исходным кодом 3.0 изменения
    хранятся в нескольких файлах заплат (описано в Раздел 5.25,
    «Файлы patches/*»). Вы можете отследить изменения каждого файла
    debian/patches/* также с помощью interdiff.

7.8. Команда mc

    Большинство этих файловых проверок могут быть сделаны интуитивно
    понятным образом с помощью файлового менеджера типа mc(1),
    который позволяет просматривать содержимое не только файлов
    пакетов *.deb, но и таких файлов как *.udeb, *.debian.tar.gz,
    *.diff.gz и *.orig.tar.gz.

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


---------------------------------------------------------------------

    ^[75] Вам не потребуется указывать параметр lintian -i -I
    --show-overrides, если вы настроили файл настройки /etc/
    devscripts.conf или ~/.devscripts, как это было описано в
    Раздел 6.3, «Команда debuild».

Глава 8. Обновление пакета

    The rewrite of this tutorial document with updated contents and
    more practical examples is available as Guide for Debian
    Maintainers. Please use this new tutorial as the primary tutorial
    document.

    Вскоре после выпуска пакета, вам понадобится его обновить.

8.1. Новая редакция Debian

    Предположим, что в вашем пакете нашли ошибку (номер #654321), и
    описываемую там проблему вы можете решить. Для того, чтобы
    создать новую редакцию пакета, нужно:

      * Если исправление должно быть записано в виде новой заплаты,
        сделайте следующее:

          + запустите dquilt new название-ошибки.patch для присвоения
            имени заплате;

          + запустите dquilt add файл-с-ошибкой для объявления файла,
            который должен быть изменён;

          + исправьте ошибку в пакете исходного кода;

          + запустите dquilt refresh для записи исправления в файл
            название-ошибки.patch;

          + запустите dquilt header -e для добавления её описания;

      * Если для исправления требуется обновление существующей
        заплаты, сделайте следующее:

          + запустите dquilt pop foo.patch для того, чтобы откатить
            наложенную заплату foo.patch;

          + исправьте проблему в старой заплате foo.patch;

          + запустите dquilt refresh для обновления заплаты foo.patch
            ;

          + запустите dquilt header -e для обновления её описания;
   
          + запустите while dquilt push; do dquilt refresh; done для
            применения всех заплат при удалении шероховатостей;

      * Добавьте новую редакцию в начало файла Debian changelog,
        например, с помощью dch -i или вручную с помощью dch -v
        версия-редакция, а затем добавьте комментарии с помощью
        текстового редактора ^[76].

      * Включите краткое описание ошибки и её решение в список
        изменений (changelog), сопроводив текстом Closes: #654321.
        Это позволит автомагически закрыть сообщение об ошибке с
        помощью программного обеспечения обслуживания архива в тот
        момент, когда ваш пакет будет принят в архив Debian.

      * Повторите то, что делали выше, для исправления других ошибок,
        обновляя файл Debian changelog с помощью dch по мере
        надобности.

      * Повторите всё из Раздел 6.1, «Полная (пере)сборка» и Глава 7,
        Проверка пакета на наличие ошибок.

      * После проверки правильности, измените в changelog имя выпуска
        с UNRELEASED на значение целевого дистрибутива unstable (или
        даже на experimental). ^[77]

      * Upload the package as in Глава 9, Отправка пакета. The
        difference is that this time, the original source archive
        won't be included, as it hasn't been changed and it already
        exists in the Debian archive.

    One tricky case can occur when you make a local package, to
    experiment with the packaging before uploading the normal version
    to the official archive, e.g., 1.0.1-1. For smoother upgrades, it
    is a good idea to create a changelog entry with a version string
    such as 1.0.1-1~rc1. You may unclutter changelog by consolidating
    such local change entries into a single entry for the official
    package. See Раздел 2.6, «Имя и версия пакета» for the order of
    version strings.

   

8.2. Изучение нового авторского выпуска

    When preparing packages of a new upstream release for the Debian
    archive, you must check the new upstream release first.

    Начните с чтения файлов changelog, NEWS и всей остальной
    документации, которая может поставляться с новой версией.

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

    $ diff -urN foo-старая-версия foo-новая-версия

    На изменения в некоторых автоматически сгенерированных файлах
    Autotools, таких как missing, aclocal.m4, config.guess,
    config.h.in, config.sub, configure, depcomp, install-sh,
    ltmain.sh и Makefile.in, можно не обращать внимания. Вы можете
    удалить их перед запуском diff для проверки исходного кода.

8.3. Новый авторский выпуск

    Если пакет foo правильно собран в новом формате 3.0 (native) или
    3.0 (quilt), то для подготовки пакета новой версии программы
    достаточно переместить старый каталог debian в новый исходный
    код. Это можно сделать запуском tar xvzf /путь/к/foo_
    старая-версия.debian.tar.gz в каталоге с новым исходным кодом ^
    [78]. Конечно, потребуется сделать несколько очевидных рутинных
    операций:

      * Скопируйте авторский исходный код в файл foo_новая-версия
        .orig.tar.gz.

      * Обновите файл Debian changelog с помощью dch -v новая-версия-
        1.

          + Добавьте пометку New upstream release.

          + Лаконично опишите изменения в новом авторском выпуске,
            которые исправляют найденные ошибки, и закройте эти
            ошибки, добавляя Closes: #номер_ошибки.

          + Лаконично опишите изменения в новом авторском выпуске,
            сделанные сопровождающим, которые исправляют найденные
            ошибки, и закройте эти ошибки, добавляя Closes: #
            номер_ошибки.

      * запустите while dquilt push; do qduilt refresh; done для
        применения всех заплат при удалении шероховатостей.

    Если наложение/слияние произошло с ошибками, изучите ситуацию
    (сведения есть в файлах .rej).

      * Если применяемая заплата к исходному коду была интегрирована
        в авторский исходный код, то

          + выполните dquilt delete для её удаления.

      * Если применяемая заплата к исходному коду конфликтует с
        новыми изменениями в авторском исходном коде, то

          + выполните dquilt push -f для наложения старых заплат с
            отбрасыванием конфликтующих baz.rej.

          + Исправьте файл baz ручным копированием нужных строки из
            baz.rej.

          + запустите dquilt refresh для обновления заплаты.

      * Продолжайте, как обычно, командой while dquilt push; do
        dquilt refresh; done.

    Это может быть автоматизировано с помощью команды uupdate(1):

    $ apt-get source foo
    ...
    dpkg-source: info: extracting foo in foo-старая-версия
    dpkg-source: info: unpacking foo_старая-версия.orig.tar.gz
    dpkg-source: info: applying foo_старая-версия-1.debian.tar.gz
    $ ls -F
    foo-старая-версия/
    foo_старая-версия-1.debian.tar.gz
    foo_старая-версия-1.dsc
    foo_старая-версия.orig.tar.gz
    $ wget http://example.org/foo/foo-новая-версия.tar.gz
    $ cd foo-старая-версия
    $ uupdate -v новая-версия ../foo-новая-версия.tar.gz
    $ cd ../foo-новая-версия
    $ while dquilt push; do dquilt refresh; done
    $ dch
    ... описание проведённых изменений

    Если вы настроили файл debian/watch по описанию из Раздел 5.21,
    «Файл watch», то можете пропустить команду wget. Просто запустите
    uscan(1) в каталоге foo-старая-версия вместо команды uupdate. Она
    автомагически найдёт обновления исходного кода, скачает его и
    запустит команду uupdate ^[79].

    Вы можете выпустить этот обновлённый исходный код, повторив то,
    что делали в Раздел 6.1, «Полная (пере)сборка», Глава 7, Проверка
    пакета на наличие ошибок и Глава 9, Отправка пакета.

8.4. Обновление стиля пакетирования

    При обновлении пакета обновлять стиль пакетирования
    необязательно. Но сделав это, вы сможете полностью использовать
    возможности современной системы debhelper и формата исходного
    кода 3.0 ^[80].

      * Если по какой-то причине требуется пересоздать удалённые
        шаблоны файлов, вы можете ещё раз запустить dh_make с
        параметром --addmissing в том же дереве исходного кода пакета
        Debian, а затем отредактировать их должным образом.

      * Если в пакете файл debian/rules не переписан с использованием
        команды dh из пакета debhelper v7+, то сделайте это. Обновите
        файл debian/control соответствующим образом.

      * Если вы хотите переписать файл rules с использованием dh, в
        котором сейчас используется механизм включения Makefile из
        Common Debian Build System (cdbs), то для понимания его
        переменных настройки DEB_* смотрите следующие документы:

          + локальная копия /usr/share/doc/cdbs/cdbs-doc.pdf.gz

          + The Common Debian Build System (CDBS), FOSDEM 2009

      * Если у вас есть пакет исходного кода формата 1.0 без файла
        foo.diff.gz, вы можете обновить его до нового формата
        исходного кода 3.0 (native), создав файл debian/source/format
        с содержимым 3.0 (native). Остальные файлы debian/* могут
        быть просто скопированы.

      * Если у вас есть пакет с исходным кодом формата 1.0 с файлом
        foo.diff.gz, вы можете обновить его до нового формата
        исходного кода 3.0 (quilt), создав файл debian/source/format
        с содержимым 3.0 (quilt). Остальные файлы debian/* могут быть
        просто скопированы. Если нужно, импортируйте файл big.diff,
        полученный командой filterdiff -z -x '*/debian/*' foo.diff.gz
        > big.diff, в вашу систему quilt ^[81].

      * Если в пакете используется другая система заплат, например,
        dpatch, dbs или cdbs с параметром -p0, -p1 или -p2, перейдите
        на quilt, используя deb3, как описано в http://
        bugs.debian.org/581186.

      * Если пакет был собран командой dh с параметром --with quilt
        или командами dh_quilt_patch и dh_quilt_unpatch, уберите их и
        перейдите на использование нового формата пакетов исходного
        кода 3.0 (quilt).

    Проверьте DEP - Debian Enhancement Proposals и учтите ПРИНЯТЫЕ
    предложения.

    Также вам нужно выполнить остальные задачи, описанные в
    Раздел 8.3, «Новый авторский выпуск».

8.5. Преобразование в UTF-8

    Если авторские документы поставляются в старых кодировках, лучше
    преобразовать их в UTF-8.

      * Для перекодирования простых файлов используйте iconv(1).

        iconv -f latin1 -t utf8 foo_in.txt > foo_out.txt

      * Для перекодирования файлов HTML в простой текст в кодировке
        UTF-8 используйте w3m(1). Выполнение данной операции должно
        проводиться при включённой локали UTF-8.

        LC_ALL=en_US.UTF-8 w3m -o display_charset=UTF-8 \
                -cols 70 -dump -no-graph -T text/html \
                < foo_in.html > foo_out.txt

8.6. Замечания по обновлению пакетов

    Here are a few reminders for updating packages:

      * Не удаляйте старые записи из changelog (на первый взгляд это
        очевидно, но были случаи случайного набора dch вместо dch
        -i).

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

      * Если в систему для сборки были внесены изменения (к счастью,
        вы узнаете об этом при изучении авторских изменений), то при
        необходимости обновите сборочные зависимости в файлах debian/
        rules и debian/control.

      * Проверьте систему отслеживания ошибок (BTS) на случай, если
        кто-нибудь предоставил заплаты для исправления незакрытых
        ошибок.

      * Проверьте содержимое файла .changes и убедитесь, что вы
        выполняете отправку в правильный дистрибутив, закрываемые
        ошибки перечислены в поле Closes, поля Maintainer и
        Changed-By совпадают, файл подписан GPG и т. д.


---------------------------------------------------------------------

    ^[76] Дату в нужном формате можно получить с помощью команды LANG
    =C date -R.

    ^[77] Если для выполнения изменения вы используете команду dch
    -r, то убедитесь, что записали файл changelog именно редактором.

    ^[78] Если пакет foo собран в старом формате 1.0, то вместо этого
    можно запустить zcat /путь/к/foo_старая-версия.diff.gz|patch -p1
    в каталоге с новым исходным кодом.

    ^[79] Если команда uscan скачает обновлённый исходный код, но не
    запустит команду uupdate, исправьте файл debian/watch таким
    образом, чтобы упоминание debian uupdate было в конце URL.

    ^[80] Не стоит беспокоиться или спорить, если ваш поручитель или
    другие сопровождающие возражают против обновления существующего
    стиля пакетирования. Есть более важные вещи.

    ^[81] Вы можете разделить файл big.diff на много маленьких
    приращиваемых заплат с помощью команды splitdiff.

Глава 9. Отправка пакета

    The rewrite of this tutorial document with updated contents and
    more practical examples is available as Guide for Debian
    Maintainers. Please use this new tutorial as the primary tutorial
    document.

    Debian now requires source-only uploads for normal upload. So
    this page is outdated.

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

9.1. Отправка в архив Debian

    После того, как вы станете официальным разработчиком ^[82], то
    сможете отправлять пакеты в архив Debian ^[83]. Вы можете делать
    это вручную, но легче воспользоваться существующими инструментами
    автоматизации, такими как dupload(1) или dput(1). Здесь будет
    рассказано как это сделать с помощью dupload ^[84].

    Сначала, вам нужно настроить конфигурационный файл для dupload.
    Вы можете отредактировать системный файл /etc/dupload.conf, либо
    создать свой собственный файл ~/.dupload.conf, указав те
    настройки, которые нужно изменить.

    Описание каждого параметра приведено в справочной странице 
    dupload.conf(5).

    Параметр $default_host определяет, какая из очередей отправки
    будет использована по умолчанию. Первичной является
    anonymous-ftp-master, но возможно, что вы захотите использовать
    другую ^[85].

    Соединившись с Интернетом, вы можете отправить свой пакет
    следующим образом:

    $ dupload gentoo_0.9.12-1_i386.changes

    Команда dupload проверяет, что контрольные суммы SHA1/SHA256
    ваших файлов совпадают с указанным в файле .changes. Если они не
    совпадают, она предложит пересобрать пакет (о том, как это
    правильно делать, смотрите раздел Раздел 6.1, «Полная (пере)
    сборка»).

    Если при отправке в ftp://ftp.upload.debian.org/pub/UploadQueue/
    возникли проблемы, то вы можете исправить их вручную загрузив
    туда файл *.commands, подписанный GPG, с помощью ftp ^[86].
    Например, используя hello.commands:

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1
    Uploader: Foo Bar <Foo.Bar@example.org>
    Commands:
     rm hello_1.0-1_i386.deb
     mv hello_1.0-1.dsx hello_1.0-1.dsc
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.10 (GNU/Linux)

    [...]
    -----END PGP SIGNATURE-----

9.2. Включение файла orig.tar.gz для отправки

    При самой первой отправке пакета в архив, вам также потребуется
    добавить к нему файл с исходным кодом orig.tar.gz. Если номер
    редакции Debian для данной версии программы не равен 1 или 0, то
    вам следует указать команде dpkg-buildpackage параметр -sa.

    Для команды dpkg-buildpackage:

    $ dpkg-buildpackage -sa

    Для команды debuild:

    $ debuild -sa

    Для команды pdebuild:

    $ pdebuild --debbuildopts -sa

    Противоположный по действию параметр -sd позволит исключить файл
    с исходным кодом orig.tar.gz.

9.3. Пропущенные отправки

    If you created multiple entries in debian/changelog by skipping
    uploads, you must create a proper *_.changes file that includes
    all changes since the last upload. This can be done by specifying
    the dpkg-buildpackage option -v with the version, e.g., 1.2.

    Для команды dpkg-buildpackage:

    $ dpkg-buildpackage -v1.2

    Для команды debuild:

    $ debuild -v1.2

    Для команды pdebuild:

    $ pdebuild --debbuildopts "-v1.2"


---------------------------------------------------------------------

    ^[82] Смотрите Раздел 1.1, «Социальная динамика Debian».

    ^[83] Существуют публично доступные архивы, например http://
    mentors.debian.net/, которые работают почти также как архив
    Debian и предоставляют зону для отправки людям, не имеющим
    статуса разработчика Debian. Вы можете создать свой архив с
    помощью инструментов, перечисленных в http://wiki.debian.org/
    HowToSetupADebianRepository. Поэтому данный раздел также будет
    полезен не только разработчикам Debian.

    ^[84] Сейчас, вероятно, пакет dput имеет больше возможностей и
    становится более популярным, чем dupload. Для его настройки
    используется системный файл /etc/dput и пользовательский ~
    /.dput.cf. Также он поддерживается службами Ubuntu без
    дополнительной настройки.

    ^[85] See Debian Developer's Reference 5.6, "Uploading a
    package".

    ^[86] Смотрите ftp://ftp.upload.debian.org/pub/UploadQueue/
    README. Или же вы можете использовать команду dcut из пакета
    dput.

Приложение A. Углублённое пакетирование

    The rewrite of this tutorial document with updated contents and
    more practical examples is available as Guide for Debian
    Maintainers. Please use this new tutorial as the primary tutorial
    document.

    Here are some hints and pointers for advanced packaging topics
    that you are most likely to deal with. You are strongly advised
    to read all the references suggested here.

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

A.1. Общие библиотеки

    Перед пакетированием общих библиотек прочтите следующие основные
    документы:

      * руководство по политике Debian, раздел 8 «Общие библиотеки»

      * руководство по политике Debian, раздел 9.1.1 «Структура
        файловой системы

      * руководство по политике Debian, раздел 10.2 «Библиотеки»

    Вот упрощённое представление, для начала:

      * Общие библиотеки — это объектные файлы в формате ELF, в
        которых содержится скомпилированный код.

      * Общие библиотеки распространяются в виде файлов *.so (не в
        файлах *.a или *.la).

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

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

      * Shared libraries export symbols, which represent compiled
        objects such as variables, functions, and classes; and enable
        access to them from the linked executables.

      * SONAME общей библиотеки libfoo.so.1: objdump -p libfoo.so.1 |
        grep SONAME ^[87]

      * SONAME общей библиотеки обычно совпадает с именем файла
        библиотеки (но не всегда).

      * SONAME общих библиотек, которые скомпонованы с /usr/bin/foo:
        objdump -p /usr/bin/foo | grep NEEDED ^[88]

      * libfoo1: библиотечный пакет общей библиотеки libfoo.so.1 с
        ABI-версией SONAME, равной 1.^[89]

      * Пакетные сценарии сопровождающего для библиотеки должны
        вызывать ldconfig для создания необходимых символьных ссылок
        для SONAME при определённых условиях.^[90]

      * libfoo1-dbg: the debugging symbols package that contains the
        debugging symbols for the shared library package libfoo1.

      * libfoo-dev: the development package that contains the header
        files etc. for the shared library libfoo.so.1.^[91]

      * Debian packages should not contain *.la Libtool archive files
        in general.^[92]

      * Debian packages should not use RPATH in general.^[93]

      * Несмотря на некоторое устаревание и статус вторичности,
        следующая ссылка тоже может быть полезна Debian Library
        Packaging Guide.

A.2. Управление debian/пакет.symbols

    When you package a shared library, you should create a debian/
    package.symbols file to manage the minimal version associated
    with each symbol for backward-compatible ABI changes under the
    same SONAME of the library for the same shared library package
    name.^[94] You should read the following primary references in
    detail:

      * Смотрите руководство по политике Debian, раздел 8.6.3
        «Система символов»^[95]

      * dh_makeshlibs(1)
   
      * dpkg-gensymbols(1)

      * dpkg-shlibdeps(1)

      * deb-symbols(5)

    Here is a rough example of how to create the libfoo1 package from
    the upstream version 1.3 with the proper debian/libfoo1.symbols
    file:

      * Подготовьте основу исходного дерева из авторского файла
        libfoo-1.3.tar.gz.

          + Если пакетирование libfoo1 производится впервые, создайте
            пустой файл debian/libfoo1.symbols.

          + Если была упакована предыдущая авторская версия 1.2 в пакет
            libfoo1 с соответствующим файлом debian/libfoo1.symbols в
            пакете с исходным кодом, то используйте его и сейчас.

          + If the previous upstream version 1.2 was not packaged with
            debian/libfoo1.symbols, create it as the symbols file from
            all available binary packages of the same shared library
            package name containing the same SONAME of the library, for
            example, versions 1.1-1 and 1.2-1. ^[96]

            $ dpkg-deb -x libfoo1_1.1-1.deb libfoo1_1.1-1
            $ dpkg-deb -x libfoo1_1.2-1.deb libfoo1_1.2-1
            $ : > symbols
            $ dpkg-gensymbols -v1.1 -plibfoo1 -Plibfoo1_1.1-1 -Osymbols
            $ dpkg-gensymbols -v1.2 -plibfoo1 -Plibfoo1_1.2-1 -Osymbols

      * Make trial builds of the source tree with tools such as debuild
        and pdebuild. (If this fails due to missing symbols etc., there
        were some backward-incompatible ABI changes that require you to
        bump the shared library package name to something like libfoo1a
        and you should start over again.)

        $ cd libfoo-1.3
        $ debuild
        ...
        dpkg-gensymbols: warning: some new symbols appeared in the symbols file: ...
         see diff output below
        --- debian/libfoo1.symbols (libfoo1_1.3-1_amd64)
        +++ dpkg-gensymbolsFE5gzx        2012-11-11 02:24:53.609667389 +0900
        @@ -127,6 +127,7 @@
          foo_get_name@Base 1.1
          foo_get_longname@Base 1.2
          foo_get_type@Base 1.1
        + foo_get_longtype@Base 1.3-1
          foo_get_symbol@Base 1.1
          foo_get_rank@Base 1.1
          foo_new@Base 1.1
        ...

      * If you see the diff printed by the dpkg-gensymbols as above,
        extract the proper updated symbols file from the generated binary
        package of the shared library. ^[97]

        $ cd ..
        $ dpkg-deb -R  libfoo1_1.3_amd64.deb libfoo1-tmp
        $ sed -e 's/1\.3-1/1\.3/' libfoo1-tmp/DEBIAN/symbols \
                >libfoo-1.3/debian/libfoo1.symbols

      * Соберите выпускаемые пакеты с помощью таких инструментов как 
        debuild и pdebuild.

        $ cd libfoo-1.3
        $ debuild -- clean
        $ debuild
        ...

    В дополнение к вышеупомянутым примерам мы должны проверить
    дальнейшую совместимость ABI и, если понадобится, увеличить
    версии некоторых символов вручную. ^[98]

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

A.3. Мультиархитектурность

    Свойство мультиархитектурности, появившееся в Debian wheezy,
    встраивает поддержку кросс-платформенной установки двоичных
    пакетов (а именно i386<->amd64, но есть и другие комбинации) в
    dpkg и apt. Подробная информация приведена в следующих
    документах:

      * вики Ubuntu MultiarchSpec (авторский документ)
   
      * вики Debian Multiarch/Implementation (ситуация в Debian)

    При установке общих библиотек в путях используются триплеты,
    например i386-linux-gnu и x86_64-linux-gnu. Актуальный триплет
    динамически задаётся в переменной $(DEB_HOST_MULTIARCH) с помощью
    dpkg-architecture(1) при каждой сборке. Например, путь установки
    мультиархитектурных библиотек изменяется следующим образом:^[99]

    
    +---------------------------------------------------------------+
    | Старый  | мультиархитектурный путь | мультиархитектурный путь |
    |  путь   |         для i386         |        для amd64         |
    |---------+--------------------------+--------------------------|
    |/lib/    |/lib/i386-linux-gnu/      |/lib/x86_64-linux-gnu/    |
    |---------+--------------------------+--------------------------|
    |/usr/lib/|/usr/lib/i386-linux-gnu/  |/usr/lib/x86_64-linux-gnu/|
    +---------------------------------------------------------------+

    Here are some typical multiarch package split scenario examples
    for the following:

      * библиотека с исходным кодом libfoo-1.tar.gz

      * инструмент с исходным кодом bar-1.tar.gz, написанный на
        компилируемом языке

      * инструмент с исходным кодом baz-1.tar.gz, написанный на
        интерпретируемом языке

    
    +-----------------------------------------------------------------+
    |   Пакет    |Архитектура:|Мультиархитектурность:|   Содержимое   |
    |            |            |                      |     пакета     |
    |------------+------------+----------------------+----------------|
    |            |            |                      |общая           |
    |libfoo1     |любая       |такая же              |библиотека,     |
    |            |            |                      |одновременная   |
    |            |            |                      |установка       |
    |------------+------------+----------------------+----------------|
    |            |            |                      |отладочные      |
    |            |            |                      |символы общей   |
    |libfoo1-dbg |любая       |такая же              |библиотеки,     |
    |            |            |                      |одновременная   |
    |            |            |                      |установка       |
    |------------+------------+----------------------+----------------|
    |            |            |                      |заголовочные    |
    |            |            |                      |файлы общей     |
    |libfoo-dev  |любая       |такая же              |библиотеки,     |
    |            |            |                      |одновременная   |
    |            |            |                      |установка       |
    |------------+------------+----------------------+----------------|
    |            |            |                      |программы       |
    |            |            |                      |поддержки       |
    |libfoo-tools|любая       |сторонняя             |времени         |
    |            |            |                      |выполнения, не  |
    |            |            |                      |одновременная   |
    |            |            |                      |установка       |
    |------------+------------+----------------------+----------------|
    |            |            |                      |файлы           |
    |libfoo-doc  |все         |сторонняя             |документации    |
    |            |            |                      |общей библиотеки|
    |------------+------------+----------------------+----------------|
    |            |            |                      |скомпилированные|
    |bar         |любая       |сторонняя             |файлы программы,|
    |            |            |                      |одновременная   |
    |            |            |                      |установка       |
    |------------+------------+----------------------+----------------|
    |            |            |                      |файлы           |
    |bar-doc     |все         |сторонняя             |документации    |
    |            |            |                      |программы       |
    |------------+------------+----------------------+----------------|
    |baz         |все         |сторонняя             |интерпретируемые|
    |            |            |                      |файлы программы |
    +-----------------------------------------------------------------+

    Заметим, что пакет для разработчика должен содержать символьную
    ссылку на соответствующую общую библиотеку без номера версии.
    Пример: /usr/lib/x86_64-linux-gnu/libfoo.so -> libfoo.so.1

A.4. Сборка пакета с общей библиотекой

    You can build a Debian library package enabling multiarch support
    using dh(1) as follows:

      * Обновите debian/control.

          + Add Build-Depends: debhelper (>=10) for the source package
            section.

          + Добавьте Pre-Depends: ${misc:Pre-Depends} для каждого
            двоичного пакета с общей библиотекой.

          + Добавьте строку Multi-Arch: в раздел каждого двоичного
            пакета.

      * Set debian/compat to "10".

      * Измените путь с обычного /usr/lib/ на мультиархитектурный /usr/
        lib/$(DEB_HOST_MULTIARCH)/ во всех сценариях пакета.

          + Call DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture
            -qDEB_HOST_MULTIARCH) in debian/rules to set the
            DEB_HOST_MULTIARCH variable first.

          + Замените /usr/lib/ на /usr/lib/$(DEB_HOST_MULTIARCH)/ в
            debian/rules.

          + If ./configure is used in part of the
            override_dh_auto_configure target in debian/rules, make sure
            to replace it with dh_auto_configure -- . ^[100]

          + Замените все появления /usr/lib/ на /usr/lib/*/ в файлах
            debian/foo.install.

          + Generate files like debian/foo.links from debian/foo.links.in
            dynamically by adding a script to the
            override_dh_auto_configure target in debian/rules.

            override_dh_auto_configure:
                    dh_auto_configure
                    sed 's/@DEB_HOST_MULTIARCH@/$(DEB_HOST_MULTIARCH)/g' \
                            debian/foo.links.in > debian/foo.links

    Проверьте, что пакет с общей библиотекой содержит только
    ожидаемые файлы и что ваши пакеты -dev ещё работают.

    All files installed simultaneously as the multiarch package to
    the same file path should have exactly the same file content. You
    must be careful of differences generated by the data byte order
    and by the compression algorithm.

A.5. Родной пакет Debian

    Если пакет сопровождается только для Debian или, возможно,
    предназначен только для локального использования, то файлы debian
    /* можно хранить прямо его в исходном коде. Есть два способа его
    пакетирования.

    You can make the upstream tarball by excluding the debian/* files
    and package it as a non-native Debian package as in Раздел 2.1,
    «Порядок сборки пакета Debian». This is the normal way, which
    some people encourage using.

    Альтернативный способ сборки родного пакета Debian:

      * создание родного пакета Debian с исходным кодом в формате 3.0
        (native), состоящем из одного сжатого файла tar, в который
        включены все файлы

          + пакет_версия.tar.gz
          + пакет_версия.dsc
      * сборка двоичных пакетов Debian из родного пакета Debian с
        исходным кодом

          + пакет_версия_архитектура.deb

    For example, if you have source files in ~/mypackage-1.0 without
    the debian/* files, you can create a native Debian package by
    issuing the dh_make command as follows:

    $ cd ~/mypackage-1.0
    $ dh_make --native

    Then the debian directory and its contents are created just like
    in Раздел 2.8, «Начальный неродной пакет Debian». This does not
    create a tarball, since this is a native Debian package. But that
    is the only difference. The rest of the packaging activities are
    practically the same.

    После выполнения команды dpkg-buildpackage, вы увидите следующие
    файлы в родительском каталоге:

      * mypackage_1.0.tar.gz

        Это сжатый архив tar с исходным кодом, созданный из каталога
        mypackage-1.0 командой dpkg-source (его суффикс не
        orig.tar.gz).

      * mypackage_1.0.dsc

        This is a summary of the contents of the source code, as in
        the non-native Debian package. (There is no Debian revision.)
   
      * mypackage_1.0_i386.deb

        This is your completed binary package, as in the non-native
        Debian package. (There is no Debian revision.)

      * mypackage_1.0_i386.changes

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


---------------------------------------------------------------------

    ^[87] Либо: readelf -d libfoo.so.1 | grep SONAME

    ^[88] Либо: readelf -d libfoo.so.1 | grep NEEDED

    ^[89] Смотрите руководство по политике Debian, раздел 8.1 «Общие
    библиотеки времени выполнения».

    ^[90] Смотрите руководство по политике Debian, раздел 8.1.1
    «ldconfig».

    ^[91] Смотрите руководство по политике Debian, раздел 8.3
    «Статические библиотеки» и руководство по политике Debian, раздел
    8.4 «Файлы для разработки».

    ^[92] Смотрите Debian wiki ReleaseGoals/LAFileRemoval.

    ^[93] Смотрите вики Debian RpathIssue.

    ^[94] При обратно несовместимых изменениях ABI обычно требуется
    обновить SONAME библиотеки и поменять имя пакета общей библиотеки
    на новое.

    ^[95] Вместо указанного для библиотек C++ и в других случаях, где
    слежение за отдельными символами слишком сложно, прочтите
    руководство по политике Debian, раздел 8.6.4 «Система shlibs».

    ^[96] Все предыдущие версии пакетов Debian доступны по http://
    snapshot.debian.org/. Для облегчения переноса пакета в старые
    выпуски часть, отвечающая за версию Debian, отбрасывается: 1.1 <<
    1.1-1~bpo70+1 << 1.1-1 и 1.2 << 1.2-1~bpo70+1 << 1.2-1

    ^[97] Для облегчения переноса пакета в старые выпуски часть,
    отвечающая за версию Debian, отбрасывается: 1.3 << 1.3-1~bpo70+1
    << 1.3-1

    ^[98] Смотрите руководство по политике Debian, раздел 8.6.2
    «Изменения ABI общей библиотеки».

    ^[99] Old special purpose library paths such as /lib32/ and /
    lib64/ are not used anymore.

    ^[100] Или же вы можете добавить параметры --libdir=\$${prefix}/
    lib/$(DEB_HOST_MULTIARCH) и --libexecdir=\$${prefix}/lib/$
    (DEB_HOST_MULTIARCH) в ./configure. Заметим, что в --libexecdir
    задаётся путь по умолчанию для установки исполняемых программ,
    запускаемых другими программами, а не пользователями. Значение
    Autotools по умолчанию равно /usr/libexec/, но значение Debian по
    умолчанию равно /usr/lib/.

