Руководство начинающего разработчика Debian --------------------------------------------------------------------- Джосип Родин первоначальный вариант  Осаму Аоки обновлённый вариант  L10N-russian Russian Translation  версия 1.2.53 --------------------------------------------------------------------- Авторские права © 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. 2022-10-08 03:52:48 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 < 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 < 5 Build-Depends: debhelper (>=10) 6 Standards-Version: 4.0.0     7 Homepage: 8 9 Package: gentoo 10 Architecture: any 11 Depends: ${shlibs:Depends}, ${misc:Depends} 12 Description: 13     (номера строк добавлены для наглядности)     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 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 4 Source: http://sourceforge.net/projects/gentoo/files/ 5 6 Files: * 7 Copyright: 1998-2010 Emil Brink 8 License: GPL-2+ 9 10 Files: icons/* 11 Copyright: 1998 Johan Hanson 12 License: GPL-2+ 13 14 Files: debian/* 15 Copyright: 1998-2010 Josip Rodin 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) 4 5 -- Josip Rodin 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 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     ----------------- -- Josip Rodin , 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 скачивается страница и в ней ищутся ссылки вида . Базовое имя (часть за последним /) каждой найденной ссылки     сравнивается с шаблоном регулярного выражения 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 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/.