Глава 6. Basics for packaging

# Глава 6. Basics for packaging

Here, a broad overview is presented without using VCS operations for the basic rules of Debian packaging focusing on the non-native Debian package in the «3.0 (quilt)» format.

| Примечание
Для ясности в дайльнейшем были умышленно опущены некоторые детали. Ознакомьтесь со страницами руководства dpkg-source(1), dpkg-buildpackage(1), dpkg(1), dpkg-deb(1), deb(5) и др.

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

The Debian binary package is a special archive file which holds a set of installable binary data with its associated information.

Один пакет Debian с исходным кодом может использоваться для создания нескольких двоичных пакетов Debian, определяемых в файле debian/control.

The non-native Debian package in the Debian source format «3.0 (quilt)» is the most normal Debian source package format.

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

## 6.1. Работа по созданию пакета

The Debian packaging workflow to create a Debian binary package involves generating several specifically named files (see «Раздел 6.3, «Имя пакета и версия»») as defined in the «Debian Policy Manual». This workflow can be summarized in 10 steps with some over simplification as follows.

1. The upstream tarball is downloaded as the package-version.tar.xz file.
2. Этот архив распаковывается, создаётся множество файлов в каталоге пакет-версия/.

3. The upstream tarball is copied (or symlinked) to the particular filename packagename_version.orig.tar.xz.

   - символ, разделяющий пакет и версию, заменяется с - (дефиса) на _ (подчёркивание)
   - к расширению добавляется .orig.

4. К исходному коду основной ветки разработки в каталог пакет-версия/debian/ добавляются файлы спецификации пакета Debian.

   - Обязательные файлы спецификации в каталоге debian/*:

     debian/rules
       Исполняемый сценарий для сборки пакета Debian (см. «Раздел 6.5, «debian/rules file»»)
     debian/control
       The package configuration file containing the source package name, the source build dependencies, the binary package name, the binary dependencies, etc. (see «Раздел 6.6, «debian/control file»»)
     debian/changelog
       Файл с историей пакета Debian, определяющий в первой строке версию пакета из основной ветки разработки и номер редакции Debian (см. «Раздел 6.7, «debian/changelog file»»)
     debian/copyright
       Информация об авторских правах и лицензии (см. «Раздел 6.8, «debian/copyright file»»)
     debian/source/format
       This indicates the desired format to dpkg-source(1) (see Debian wiki: «DebSrc3.0»)
   - Необязательные файлы спецификации в каталоге debian/* (see «Раздел 6.14, «Other debian/* files»»):
   - These files must be manually edited to their perfection according to the «Debian Policy Manual» and «Debian Developer’s Reference».

5. The dpkg-buildpackage command (usually from its wrapper debuild or sbuild) is invoked in the package-version/ directory to make the Debian source and binary packages by invoking the debian/rules script.

   - The current directory is set as: «CURDIR=/path/to/package-version/»

   - Create the Debian source package in the Debian source format «3.0 (quilt)» using dpkg-source(1)

     - package_version.orig.tar.xz (copy or symlink of package-version.tar.xz)
     - package_version-revision.debian.tar.xz (tarball of debian/ found in package-version/)
     - package_version-revision.dsc

   - Build the source using «debian/rules build» into $(DESTDIR)

     - «DESTDIR=debian/binarypackage/» for single binary package [11]
     - «DESTDIR=debian/tmp/» for multi binary package

   - Создание двоичного пакета Debian с помощью dpkg-deb(1), dpkg-genbuildinfo(1) и dpkg-genchanges(1).

     - двоичныйпакет_версия-редакция_архитектура.deb
     - …​ (There may be multiple Debian binary package files.)
     - пакет_версия-редакция_архитектура.changes
     - package_version-revision_arch.buildinfo

6. Проверка качества пакета Debian с помощью команды lintian. (рекомендуется)

   - Follow the rejection guidelines from ftp-master.

     - «REJECT-FAQ»
     - «Лист проверок для пакетов из NEW»
     - «Автоматические отклонения пакетов Lintian» («список тегов lintian»)
7. Test the goodness of the generated Debian binary package manually by installing it and running its programs.
8. After confirming the goodness, prepare files for the normal source-only upload to the Debian archive.

9. Sign the Debian package file with the debsign command using your private openPGP key.

   - Use «debsign package_version-revision_source.changes» (source-only upload situation)
   - Use «debsign package_version-revision_arch.changes» (source+binary upload situation)

10. Upload the set of the Debian package files with the dput command to the Debian archive.

    - Use «dput package_version-revision_source.changes» (source-only upload)
    - Use «dput package_version-revision_arch.changes» (source+binary upload)

Test building and confirming of the binary package goodness as above is the moral obligation as a diligent Debian developer but there is no physical barrier for people to skip such operations at this moment for the source-only upload.

For the upstream tarball, the debmake command helps up to the step 4 in the above workflow. For the upstream working tree package/ checked out, e.g., by «git clone https://github.com/upstreamname/package.git» without any upstream tarball, the debmake command invoked in it helps up to step 4, too. The debmake command does not overwrite any existing configuration files.

Теперь замените каждую часть имени файла.

- часть пакет на имя пакета Debian с исходным кодом
- часть двоичныйпакет на имя двоичного пакета Debian
- часть версия на версию основной ветки разработки
- часть редакция на номер редации Debian
- the arch part with the package architecture (e.g., amd64)

The current Debian practice for uploading the normal Debian package is:

- Use the source-only upload if all generated binary packages exist in the Debian sid archive. This is usual case.
- Use the source+binary upload if any one of generated packages is missing in the Debian sid archive. (This involves manually handled NEW process by the archive management team.)

See also «Source-only uploads».

| Подсказка
Использется множество различных стратегий по управлению заплатами и использованию систем управления версиями. Вам не следует использовать все из них.

| Подсказка
There is very extensive documentation in «Chapter 6. Best Packaging Practices» in the «Debian Developer’s Reference». Please read it.

## 6.2. debhelper package

Although a Debian package can be made by writing a debian/rules script without using the debhelper package, it is impractical to do so. There are too many modern «Debian Policy» required features to be addressed, such as application of the proper file permissions, use of the proper architecture dependent library installation path, insertion of the installation hook scripts, generation of the debug symbol package, generation of package dependency information, generation of the package information files, application of the proper timestamp for reproducible build, etc.

Debhelper package provides a set of useful scripts in order to simplify Debian’s packaging workflow and reduce the burden of package maintainers. When properly used, they will help packagers handle and implement «Debian Policy» required features automatically.

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

- using the dh command to invoke many utility scripts automatically from the debhelper package, and
- настройка их поведения с помощью декларативных файлов настройки в каталоге debian/.

You should almost always use debhelper as your package’s build dependency. This document also assumes that you are using a fairly contemporary version of debhelper to handle packaging works in the following contents.

| Примечание
For debhelper «compat >= 9», the dh command exports compiler flags (CFLAGS, CXXFLAGS, FFLAGS, CPPFLAGS and LDFLAGS) with values as returned by dpkg-buildflags if they are not set previously. (The dh command calls set_buildflags defined in the Debian::Debhelper::Dh_Lib module.)

| Примечание
debhelper(1) changes its behavior with time. Please make sure to read debhelper-compat-upgrade-checklist(7) to understand the situation.

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

If the upstream source comes as hello-0.9.12.tar.xz, you can take hello as the upstream source package name and 0.9.12 as the upstream version.

There are some limitations for what characters may be used as a part of the Debian package. The most notable limitation is the prohibition of uppercase letters in the package name. Here is a summary as a set of regular expressions:

- Upstream package name (-p): `[-+.a-z0-9]{2,}`
- Binary package name (-b): `[-+.a-z0-9]{2,}`
- Upstream version (-u): `[0-9][-+.:~a-z0-9A-Z]*`
- Debian revision (-r): `[0-9][+.~a-z0-9A-Z]*`

See the exact definition in «Chapter 5 - Control files and their fields» in the «Debian Policy Manual».

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

Для того, чтобы информация об имени пакета и номере версии эффективно обрабатывались такими популярными инструментами как команда aptitude, рекомендуется, чтобы длина имени пакета была равна 30 символам или была меньше; а общая длина версии и редакции была равна 14 символам или меньше. [12]

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

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 the dpkg command interprets later versions correctly as upgrades. If you need to ensure a smooth transition to a normal version scheme such as 0.1 in the future, use the 0~YYMMDD format such as 0~110429 as upstream version, instead.

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

    [~] $ dpkg --compare-versions ver1 op ver2

Правило сравнения версий может быть представлены следующим образом:

- Строки сравниваются в порядке с начала до конца.
- Буквы больше чисел.
- Числа сравниваются как целые числа.
- Буквы сравниваются в порядке таблицы кодов 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

One tricky case occurs when the upstream releases hello-0.9.12-ReleaseCandidate-99.tar.xz as the pre-release of hello-0.9.12.tar.xz. You can ensure the Debian package upgrade to work properly by renaming the upstream source to hello-0.9.12~rc99.tar.xz.

## 6.4. Родной пакет Debian

The non-native Debian package in the Debian source format «3.0 (quilt)» is the most normal Debian source package format. The debian/source/format file should have «3.0 (quilt)» in it as described in dpkg-source(1). The above workflow and the following packaging examples always use this format.

A native Debian package is the rare Debian binary package format. It may be used only when the package is useful and valuable only for Debian. Thus, its use is generally discouraged.

| Внимание
A native Debian package is often accidentally built when its upstream tarball is not accessible from the dpkg-buildpackage command with its correct name package_version.orig.tar.xz . This is a typical newbie mistake caused by making a symlink name with «-» instead of the correct one with «_».

A native Debian package has no separation between the upstream code and the Debian changes and consists only of the following:

- package_version.tar.xz (copy or symlink of package-version.tar.xz with debian/* files.)
- package_version.dsc

If you need to create a native Debian package, create it in the Debian source format «3.0 (native)» using dpkg-source(1).

| Подсказка
There is no need to create the tarball in advance if the native Debian package format is used. The debian/source/format file should have «3.0 (native)» in it as described in dpkg-source(1) and The debian/source/format file should have the version without the Debian revision (1.0 instead of 1.0-1). Then, the tarball containing is generated when «dpkg-source -b» is invoked in the source tree.

## 6.5. debian/rules file

The debian/rules file is the executable script which re-targets the upstream build system to install files in the $(DESTDIR) and creates the archive file of the generated files as the deb file. The deb file is used for the binary distribution and installed to the system using the dpkg command.

The Debian policy compliant debian/rules file supporting all the required targets can be written as simple as [13]:

Простой файл debian/rules:

    #!/usr/bin/make -f
    #export DH_VERBOSE = 1

    %:
    	dh $@

The dh command functions as the sequencer to call all required «dh target» commands at the right moment. [14]

- dh clean : вычищет файлы в дереве исходного кода.
- dh build : сборка дерева исходного кода
- dh build-arch : сборка зависящих от архитектуры пакетов из дерева исходного кода
- dh build-indep : сборка независящих от архитектуры пакетов из дерева исходного кода
- dh install : установка двоичных файлов в $(DESTDIR)
- dh install-arch : установка двоичных файлов в $(DESTDIR) для зависящих от архитектуры пакетов
- dh install-indep : установка двоичных файлов в $(DESTDIR) для независящих от архитектуры пакетов
- dh binary : создание файла deb
- dh binary-arch : создание файла deb для зависящих от архитектуры пакетов
- dh binary-indep : создание файла deb для независящих от архитектуры пакетов

Here, $(DESTDIR) path depends on the build type.

- «DESTDIR=debian/binarypackage/» for single binary package [15]
- «DESTDIR=debian/tmp/» for multi binary package

See «Раздел 9.2, «Customized debian/rules»» and «Раздел 9.3, «Variables for debian/rules»» for customization.

| Подсказка
Setting «export DH_VERBOSE = 1» outputs every command that modifies files on the build system. Also it enables verbose build logs for some build systems.

## 6.6. debian/control file

The debian/control file consists of blocks of metadata separated by blank lines. Each block of metadata defines the following, in this order:

- метаданных пакета Debian с исходным кодом
- метаданные двоичных пакетов Debian

See «Chapter 5 - Control files and their fields» of the "Debian Policy Manual" for the definition of each metadata field.

| Примечание
The debmake command sets the debian/control file with «Build-Depends: debhelper-compat (= 14)» to set the debhelper compatibility level.

| Подсказка
If an existing package has a debhelper compatibility level lower than 14, it’s probably time to update its packaging.

## 6.7. debian/changelog file

The debian/changelog file records the Debian package history.

- Edit this file using the debchange command (alias dch).
- The first line defines the upstream package version and the Debian revision.

- Document changes in a specific, formal, and concise style.

  - If Debian maintainer modification fixes reported bugs, add «Closes: #<bug_number>» to close those bugs.

- Even if you’re uploading your package yourself, you must document all non-trivial user-visible changes, such as:

  - Security-related bug fixes.
  - User interface changes.

- If you’re asking a sponsor to upload it, document changes more comprehensively, including all packaging-related ones, to help with package review.

  - The sponsor shouldn’t have to guess your reasoning behind package changes.
  - Remember that the sponsor’s time is valuable.

After finishing your packaging and verifying its quality, execute the "dch -r" command and save the finalized debian/changelog file with the suite normally set to unstable. [16] If you’re packaging for backports, security updates, LTS, etc., use the appropriate distribution names instead.

The debmake command creates the initial template file with the upstream package version and the Debian revision. The distribution is set to UNRELEASED to prevent accidental uploads to the Debian archive.

| Подсказка
The date string used in the debian/changelog file can be manually generated by the «LC_ALL=C date -R» command.

| Подсказка
Use a debian/changelog entry with a version string like 1.0.1-1~rc1 when experimenting. Later, consolidate such changelog entries into a single entry for the official package.

The debian/changelog file is installed in the /usr/share/doc/binarypackage directory as changelog.Debian.gz by the dh_installchangelogs command.

Журнал изменений основной ветки устанавливается в каталог /usr/share/doc/двоичныйпакет под именем changelog.gz.

The upstream changelog is automatically found by the dh_installchangelogs using the case insensitive match of its file name to changelog, changes, changelog.txt, changes.txt, history, history.txt, or changelog.md and searched in the ./ doc/ or docs/ directories.

## 6.8. debian/copyright file

Debian takes copyright and license matters very seriously. The "Debian Policy Manual" requires a summary of these in the debian/copyright file of the package.

- «12.5. Copyright information»
- «2.3. Copyright considerations»
- «License information»

The debmake command creates the initial debian/copyright template file using the licensecheck(1) command.

## 6.9. debian/patches/* files

As demonstrated in «Раздел 5.9, «Step 3 (alternatives): Modification to the upstream source»», the debian/patches/ directory holds

- patch-file-name.patch files providing -p1 patches and
- the series file which defines how these patches are applied.

See how these files are used in:

- «Раздел 13.6, «dpkg-source -b»» to build the Debian source package
- «Раздел 13.7, «dpkg-source -x»» to extract source files from the Debian source package

| Примечание
Header texts of these patches should conform to «DEP-3».

| Примечание
If you want to use VCS tools such as git, gbp and dgit to create and manage these patches after learning basics here, please refer to later in «Глава 11, Packaging with git».

## 6.10. debian/source/include-binaries file

The «dpkg-source --commit» command functions like dquilt but has one advantage over the dquilt command. The dquilt command can’t handle modified binary files since they are not representable in a diff. Also, adding binary files under the debian/ directory is normally rejected by dpkg-source. By listing these binary files in debian/source/include-binaries, the maintainer can include these binary files to the Debian source package generated by dpkg-source.

## 6.11. debian/watch file

| Примечание
This file is for use by the Debian non-native package.

The uscan(1) command downloads the latest upstream version using the debian/watch file. E.g.:

Basic debian/watch file:

    version=4
    https://ftp.gnu.org/gnu/hello/ @PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@

The uscan command may verify the authenticity of the upstream tarball with optional configuration (see «Раздел 6.12, «debian/upstream/signing-key.asc file»»).

See uscan(1), «Раздел 9.4, «Новый выпуск основной ветки»», «Раздел 8.1, «Fix with Files-Excluded»», and «Раздел 11.7, «Manage patch queue with gbp-pq»» for more.

## 6.12. debian/upstream/signing-key.asc file

Some packages are signed by a openPGP key and their authenticity can be verified using their public openPGP key.

For example, «GNU hello» can be downloaded via HTTP from https://ftp.gnu.org/gnu/hello/ . There are sets of files:

- hello-version.tar.xz (upstream source)
- hello-version.tar.xz.sig (detached signature)

Выберем самую последнюю версию.

Download the upstream tarball and its signature.

    [base_dir] $ wget https://ftp.gnu.org/gnu/hello/hello-2.9.tar.xz
     ...
    [base_dir] $ wget https://ftp.gnu.org/gnu/hello/hello-2.9.tar.xz.sig
     ...
    [base_dir] $ gpg --verify hello-2.9.tar.xz.sig
    gpg: Signature made Thu 10 Oct 2013 08:49:23 AM JST using DSA key ID 80EE4A00
    gpg: Can't check signature: public key not found

If you know the public openPGP key of the upstream maintainer from the mailing list, use it as the debian/upstream/signing-key.asc file. Otherwise, use the hkp keyserver and check it via your web of trust.

Download public openPGP key for the upstream.

    [base_dir] $ gpg --keyserver hkp://keys.gnupg.net --recv-key 80EE4A00
    gpg: requesting key 80EE4A00 from hkp server keys.gnupg.net
    gpg: key 80EE4A00: public key "Reuben Thomas <rrt@sc3d.org>" imported
    gpg: no ultimately trusted keys found
    gpg: Total number processed: 1
    gpg:               imported: 1
    [base_dir] $ gpg --verify hello-2.9.tar.xz.sig
    gpg: Signature made Thu 10 Oct 2013 08:49:23 AM JST using DSA key ID 80EE4A00
    gpg: Good signature from "Reuben Thomas <rrt@sc3d.org>"
      ...
    Primary key fingerprint: 9297 8852 A62F A5E2 85B2  A174 6808 9F73 80EE 4A00

| Подсказка
If your network environment blocks access to the HKP port 11371, use «hkp://keyserver.ubuntu.com:80» instead.

After confirming the key ID 80EE4A00 is a trustworthy one, download its public key into the debian/upstream/signing-key.asc file.

Set public openPGP key to debian/upstream/signing-key.asc.

    [base_dir] $ gpg --armor --export 80EE4A00 >debian/upstream/signing-key.asc

With the above debian/upstream/signing-key.asc file and the following debian/watch file, the uscan command can verify the authenticity of the upstream tarball after its download. E.g.:

Improved debian/watch file with openPGP support:

    version=4
    opts="pgpsigurlmangle=s/$/.sig/" \
    https://ftp.gnu.org/gnu/hello/ @PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@

## 6.13. debian/salsa-ci.yml file

Install Salsa CI configuration file. See «Раздел 11.3, «Salsa CI service»».

## 6.14. Other debian/* files

В каталог debian/ можно добавить дополнительные файлы настройки. Большинство из них используются для управления командами dh_*, предоставляемыми пакетом debhelper, но также имеются дополнительные файлы для команд dpkg-source, lintian и gbp.

| Подсказка
Even an upstream source without its build system can be packaged just by using these files. See «Раздел 14.2, «Без Makefile (командная оболочка, интерфейс командной оболочки)»» as an example.

The alphabetical list of notable optional debian/binarypackage.* configuration files listed below provides very powerful means to set the installation path of files. Please note:

- The «-x[01234]» superscript notation that appears in the following list indicates the minimum value for the debmake -x option that generates the associated template file. See «Раздел 16.4, «debmake -x»» or debmake(1) for details.
- For a single binary package, the «binarypackage.» part of the filename in the list may be removed.
- For a multi binary package, a configuration file missing the «binarypackage» part of the filename is applied to the first binary package listed in the debian/control.
- When there are many binary packages, their configurations can be specified independently by prefixing their name to their configuration filenames such as «package-1.install», «package-2.install», etc.
- Некоторые шаблонные файлы настроек могут не быть созданы командой debmake. В таких случаях вам следует создать их с помощью редактора.
- Some configuration template files generated by the debmake command with an extra .ex suffix need to be activated by removing that suffix.
- The debmake -B command adds template files with an extra .ex suffix for all existing template files without .ex and they need to be activated by removing that suffix.
- Неиспользуемые шаблонные файлы настроек, созданные командой debmake, следует удалить.

- Копируйте шаблонные файлы настроек по необходимости в файлы с соответствующими именами двоичных пакетов.

  binarypackage.bug-control -x2
    устанавливается как usr/share/bug/двоичныйпакет/control в двоичныйпакет. См. «Раздел 9.11, «Bug reports»».
  binarypackage.bug-presubj -x2
    устанавливается как usr/share/bug/двоичныйпакет/presubj в binarypackage. См. «Раздел 9.11, «Bug reports»».
  binarypackage.bug-script -x2
    устанавливается как usr/share/bug/двоичныйпакет или usr/share/bug/двоичныйпакет/script в двоичныйпакет. См. «Раздел 9.11, «Bug reports»».
  двоичныйпакет.bash-completion

    List bash completion scripts to be installed.

    The bash-completion package is required for both build and user environments.

    См. dh_bash-completion(1).

  clean -x1

    List files that should be removed but are not cleaned by the dh_auto_clean command.

    См. dh_auto_clean(1) и dh_clean(1).

  compat -x4

    Set the debhelper compatibility level. (deprecated)

    Use «Build-Depends: debhelper-compat (= 14)» in debian/control to specify the compatibility level and remove debian/compat.

    See «COMPATIBILITY LEVELS» in debhelper(7).

  binarypackage.conffiles -x3

    This optional file is installed into the DEBIAN directory within the binary package while supplementing it with all the conffiles auto-detected by debhelper.

    This file is primarily useful for using "special" entries such as the remove-on-upgrade feature from dpkg(1).

    If the program you’re packaging requires every user to modify the configuration files in the /etc directory, there are two popular ways to arrange for them not to be conffiles, keeping the dpkg command happy and quiet.

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

    См. dh_installdeb(1).

  двоичныйпакет.config
    Это config-сценарий debconf, используемый для того, чтобы задавать пользователю любые необходимые для настройки пакета вопросы. См. «Раздел 10.22, «debconf»».
  двоичныйпакет.cron.hourly -x3

    Устанавливается в файл etc/cron/hourly/двоичныйпакет в двоичныйпакет.

    См. dh_installcron(1) и cron(8).

  двоичныйпакет.cron.daily -x3

    Устанавливается в файл etc/cron/daily/двоичныйпакет в двоичныйпакет.

    См. dh_installcron(1) и cron(8).

  двоичныйпакет.cron.weekly -x3

    Устанавливается в файл etc/cron/weekly/двоичныйпакет в двоичныйпакет.

    См. dh_installcron(1) и cron(8).

  двоичныйпакет.cron.monthly -x3

    Installed into the *etc/cron/monthly/*binarypackage file in binarypackage.

    См. dh_installcron(1) и cron(8).

  двоичныйпакет.cron.d -x3

    Устанавливается в файл etc/cron.d/двоичныйпакет в двоичныйпакет.

    См. dh_installcron(1), cron(8) и crontab(5).

  двоичныйпакет.default -x3

    Если такой файл существует, то он устанавливается в etc/default/двоичныйпакет в двоичныйпакет.

    См. dh_installinit(1).

  binarypackage.dirs -x1

    Содержит список каталогов, которые должны быть созданы в двоичныйпакет.

    См. dh_installdirs(1).

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

  binarypackage.doc-base -x1

    Устанавливается как управляющий файл doc-base в двоичныйпакет.

    See dh_installdocs(1) and «Debian doc-base Manual (doc-base.html)» provided by the doc-base package.

  binarypackage.docs -x1

    Создержит список файлов документации для их установки в двоичныйпакет.

    См. dh_installdocs(1).

  binarypackage.emacsen-compat

    Устанавливается в usr/lib/emacsen-common/packages/compat/двоичныйпакет в binarypackage.

    См. dh_installemacsen(1).

  двоичныйпакет.emacsen-install -x3

    Устанавливается в usr/lib/emacsen-common/packages/install/двоичныйпакет в двоичныйпакет.

    См. dh_installemacsen(1).

  двоичныйпакет.emacsen-remove -x3

    Устанавливается в usr/lib/emacsen-common/packages/remove/двоичныйпакет в двоичныйпакет.

    См. dh_installemacsen(1).

  двоичныйпакет.emacsen-startup -x3

    Устанавливается в usr/lib/emacsen-common/packages/startup/двоичныйпакет в двоичныйпакет.

    См. dh_installemacsen(1).

  binarypackage.examples -x1

    Содержит список файлов или каталогов с примерами для их установки в usr/share/doc/двоичныйпакет/examples/ в двоичныйпакет.

    См. dh_installexamples(1).

  gbp.conf -x1

    Если этот файл существует, то он используется как файл настройки для команды gbp.

    См. gbp.conf(5), gbp(1) и git-buildpackage(1).

  binarypackage.info -x1

    Содержит список info-файлов для их установки в двоичныйпакет.

    См. dh_installinfo(1).

  binarypackage.init -x4

    Installed into etc/init.d/binarypackage in binarypackage. (deprecated)

    См. dh_installinit(1).

  binarypackage.install -x1

    Содержит список файлов, которые должны быть установлены, но не устанавливаются командой dh_auto_install.

    См. dh_install(1) и dh_auto_install(1).

  binarypackage.links -x1

    List pairs of source and destination files to be symlinked. Each pair should be put on its own line, with the source and destination separated by whitespace.

    См. dh_link(1).

  binarypackage.lintian-overrides -x2

    Устанавливается в usr/share/lintian/overrides/двоичныйпакет в каталоге сборки пакета. Этот файл используется для блокировки ошибочных диагностических процедур lintian.

    См. dh_lintian(1), lintian(1) и «Руководство пользователя Lintian».

  binarypackage.maintscript -x2

    If this optional file exists, debhelper uses this as the template to generate DEBIAN/binarypackage.{pre,post}{inst,rm} files within the binary package while adding «-- "$@"» to the dpkg-maintscript-helper(1) command.

    See dh_installdeb(1) and «Chapter 6 - Package maintainer scripts and installation procedure» in the «Debian Policy Manual».

  manpage.* -x2

    Команда debmake создаёт шаблонные файы страниц руководства. Переименуйте эти файлы соответствующим образом и обновите их содержимое.

    Debian Policy requires that each program, utility, and function should have an associated manual page included in the same package. Manual pages are written in nroff(1). If you are new to making a manpage, use manpage.asciidoc -x3 or manpage.1 -x3 as the starting point.

  binarypackage.manpages -x1

    Содержит список страниц руководства для их установки.

    См. dh_installman(1).

  двоичныйпакет.menu (устарел, более не устанавливается)

    tech-ctte #741573 decided «Debian should use .desktop files as appropriate».

    Файл меню Debian устанавливается в usr/share/menu/двоичныйпакет в двоичныйпакет.

    Информацию о формате см. в menufile(5). См. dh_installmenu(1).

  NEWS

    Устанавливается в usr/share/doc/двоичныйпакет/NEWS.Debian.

    См. dh_installchangelogs(1).

  patches/*

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

    Команда debmake не создаёт файлы заплат.

    См. dpkg-source(1), «Раздел 4.4, «quilt setup»» и «Раздел 5.9, «Step 3 (alternatives): Modification to the upstream source»».

  patches/series -x1
    Последовательность применения файлов заплат patches/*.
  binarypackage.preinst -x3, binarypackage.postinst -x3, binarypackage.prerm -x3, binarypackage.postrm -x3

    If these optional files exist, the corresponding files are installed into the DEBIAN directory within the binary package after enriched by debhelper. Otherwise, these files in the DEBIAN directory within the binary package is generated by debhelper.

    Whenever possible, simpler binarypackage.maintscript should be used instead.

    See dh_installdeb(1) and «Chapter 6 - Package maintainer scripts and installation procedure» in the «Debian Policy Manual».

    See also debconf-devel(7) and «3.9.1 Prompting in maintainer scripts» in the «Debian Policy Manual».

  README.Debian -x1

    Устанавливается в первый двоичный пакет, указанный в файле debian/control как usr/share/doc/двоичныйпакет/README.Debian.

    Этот файл содержит специальную информацию о пакете Debian.

    См. dh_installdocs(1).

  README.source -x1

    Installed into the first binary package listed in the debian/control file as usr/share/doc/binarypackage/README.source.

    If running «dpkg-source -x» on a source package doesn’t produce the source of the package, ready for editing, and allow one to make changes and run dpkg-buildpackage to produce a modified package without taking any additional steps, creating this file is recommended.

    See «Debian policy manual section 4.14».

  двоичныйпакет.service -x3

    Если этот файл существует, то он устанавливается в lib/systemd/system/двоичныйпакет.service в binarypackage.

    См. dh_systemd_enable(1), dh_systemd_start(1) и dh_installinit(1).

  source/format -x1

    Формат пакета Debian.

    - Use «3.0 (quilt)» to make this non-native package (popular)
    - Use «3.0 (native)» to make this native package

    See «SOURCE PACKAGE FORMATS» in dpkg-source(1).

  source/lintian-overrides -x2

    This file is not installed, but is scanned by the lintian command to provide overrides for the source package.

    См. dh_lintian(1) и lintian(1).

  source/local-options and source/local-patch-header -x4

    | Примечание
    These files are not compatible with the dgit workflow. See «Раздел 11.14, «Note on dgit»».

    There is no reason to use these with the current version of dpkg-source(1).

  source/options -x2

    The dpkg-source command uses this content as its options. This is typically used with «Раздел 11.13, «Patch applied Git repository»» and options may be:

    - auto-commit
    - single-debian-patch

    This is included in the generated source package.

    See «FILE FORMATS» in dpkg-source(1).

  source/patch-header -x2

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

    This is included in the generated source package and is meant to be committed to the "`Раздел 11.13, «Patch applied Git repository»`.".

    See «FILE FORMATS» in dpkg-source(1).

  binarypackage.symbols -x1

    Файлы символов. Если эти файлы существуют, то они будут переданы для обработки и установки команде dpkg-gensymbols.

    См. dh_makeshlibs(1) и «Раздел 10.16, «Библиотека символов»»..

  binarypackage.templates
    Это файл шаблонов для debconf. Он используется для вывода вопросов, необходимых для настройки пакета. См. «Раздел 10.22, «debconf»».
  tests/control -x1
    This is the RFC822-style test meta data file defined in DEP-8. See autopkgtest(1) and «Раздел 10.4, «Непрерывная интеграция»».
  TODO

    Устанавливается в первый двоичный пакет, указанный в файле debian/control как usr/share/doc/двоичныйпакет/TODO.Debian.

    См. dh_installdocs(1).

  двоичныйпакет.tmpfile -x3

    Если этот файл существует, то он устанавливается в usr/lib/tmpfiles.d/двоичныйпакет.conf в двоичныйпакет.

    См. dh_systemd_enable(1), dh_systemd_start(1) и dh_installinit(1).

  binarypackage.upstart -x4

    If this exists, it is installed into etc/init/package.conf in the package build directory. (deprecated)

    См. dh_installinit(1).

  upstream/metadata -x1
    Per-package machine-readable metadata about upstream (DEP-12). See «Upstream MEtadata GAthered with YAml (UMEGAYA)».

[11] This is the default up to debhelper v13. At debhelper v14, it warns the default change. After debhelper v15, it will change the default to DESTDIR=debian/tmp/ .

[12] Для более чем 90% пакетов длина имени пакета равна 24 символам или меньше этого числа; длина версии основной ветки равна 10 символам или меньше, а длина номера редакции Debian равна 3 символам или меньше.

[13] Команда debmake создаёт несколько более сложный файл debian/rules. Тем не менее, это базовая часть.

[14] This simplicity is available since version 7 of the debhelper package. This guide assumes the use of debhelper version 14 or newer.

[15] This is the default up to debhelper v13. At debhelper v14, it warns the default change. After debhelper v15, it will change the default to DESTDIR=debian/tmp/ .

[16] If you’re using the vim editor, make sure to save this with the ":wq" command.

Глава 5. Simple packaging |  | Глава 7. Quality of packaging