| Chapter 5. Основы | ||
|---|---|---|
 |
 |
|
| Chapter 5. Основы | ||
|---|---|---|
| |
|
|
Table of Contents
A broad overview is presented here for the basic rules of Debian packaging focusing on the non-native Debian package in the “3.0 (quilt)” format.
![[Note]](images/note.png)
|
Note |
|---|---|
|
Для ясности в дайльнейшем были умышленно опущены некоторые детали. Ознакомьтесь со страницами руководства 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.
Неродной пакет Debian в формате «3.0 (quilt)» является наиболее обычным форматом пакетов Debian с исходным кодом.
|
|
Note |
|---|---|
|
Сущесвтует множество обёрточных сценариев. Используйте их для упрощения вашей работы, но обязательно разберитесь с основами их внутреннего устройства. |
The Debian packaging workflow to create a Debian binary package involves generating several specifically named files (see Section 5.4, “Имя пакета и версия”) as defined in the “Debian Policy Manual”.
The oversimplified method for the Debian packaging workflow can be summarized in 10 steps as follows.
Архив основной ветки разработки копируется (или создаётся символьная ссылка на него) в файл со специальным именем имяпакета_версия.orig.tar.gz.
К исходному коду основной ветки разработки в каталог пакет-версия/debian/ добавляются файлы спецификации пакета Debian.
Обязательные файлы спецификации в каталоге debian/*:
Команда debmake, запущенная в каталоге пакет-версия/, создаёт изначальный набор шаблонных файлов настройки.
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.
Создание пакета Debian с исходным кодом в формате «3.0 (quilt)» с помощью dpkg-source(1)
Сборка исходного кода с помощью «debian/rules build» в $(DESTDIR)
Создание двоичного пакета Debian с помощью dpkg-deb(1), dpkg-genbuildinfo(1) и dpkg-genchanges(1).
Проверка качества пакета Debian с помощью команды lintian. (рекомендуется)
Follow the rejection guidelines from ftp-master.
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.
Under some exceptional situation such as NEW uploads, uploads to the Debian archive may need to include Debian binary package files. For such situation, sign package_version-revision_arch.changes instead of 'package_version-revision’_*source.changes* in the step 9, and upload the set of the Debian source and binary package files in the step 10.
Теперь замените каждую часть имени файла.
See also Source-only uploads.
![[Tip]](images/tip.png)
|
Tip |
|---|---|
|
Использется множество различных стратегий по управлению заплатами и использованию систем управления версиями. Вам не следует использовать все из них. |
|
|
Tip |
|---|---|
|
There is very extensive documentation in Chapter 6. Best Packaging Practices in the “Debian Developer’s Reference”. Please read it. |
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 “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 “Policy” required features automatically.
Процедура создания пакета 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.
Let me oversimplify historical perspective of Debian packaging practices.
Debian
was started in 1990s when upstream packages were available from
public FTP sites such as Sunsite. In those early
days, Debian packaging used dpkg-source currently known as "Format:
1.0":
In order to address issues of old dpkg-source "Format:
1.0", new dpkg-source "Format: 3.0 (quilt)" was
invented around 2008:
Format:
3.0 (quilt)" to manage topic patches and made Debian packages
while keeping files outside of debian/ directory
untouched.
gbp-buildpackage(1)
style.
gbp-buildpackage(1) workflow records the exact same
content of the upstream tarball to VCS for source files outside of
debian/ directory (= patch-unapplied).
The use of Git repositories to distribute upstream packages with signed tags (supported feature since 2011) became very popular.
gbp-buildpackage(1) workflow to
record changes to VCS was cumbersome for some Debian developers and
dgit(1) was invented in 2013.
dgit-maint-debrebase(7) and
dgit-maint-merge(7) workflows to record changes to VCS
are gaining popularity among these Debian developers.
dgit-maint-debrebase(7)
and git-maint-merge(7) are modified upstream source files
(= patch-applied).
dgit-maint-debrebase(7) and
git-maint-merge(7) workflows still use dpkg-source
"Format: 3.0 (quilt)".
Debian also enforced the source-only upload when developing Debian/11 Bullseye (released in 2021).
In this tutorial, mostly simple tarball based dpkg-source "Format:
3.0 (quilt)" examples are presented as an introductory purpose.
Please assess these VCS usage approaches by yourself later to decide which one to deploy as your preferred one.
Please also read Notes on Debian by Russ Allbery which have best practices such as Using Git for Debian Packaging.
Please look around to understand how Debian packaging practices are evolving and follow the current general trends if possible.
DEP - Debian Enhancement Proposals
Debian git packaging maintainer branch formats and workflows
dgit tool providers.
You can also search entire Debian source code by yourself, too.
Debian Sources — code search tool
Если исходный код основной ветки разработки поставляется в виде архива hello-0.9.12.tar.gz, можно использовать hello в качестве имени пакета с исходным кодом основной ветки разработки, а 0.9.12 — в качестве версии основной ветки.
Утилита debmake предназначена для создания шаблонных файлов в помощью сопровождающему пакета. Строчки с комментариями начинаются с символа # и содержат обучающий текст. Вам следует удалить или отредактировать строки с комментариями до выполнения загрузки пакета в архив Debian.
The license extraction and assignment process involves a lot of heuristics; it may fail in some cases. It is highly recommended to use other tools such as licensecheck from the devscripts package in conjunction with debmake.
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:
See the exact definition in Chapter 5 - Control files and their fields in the “Debian Policy Manual”.
debmake предполагает относительно простые случаи создания пакетов. Поэтому все программы, относящиеся е интерпретатору, считаются «Architecture: all». Тем не менее, это не всегда так.
Вам следует соответствующим образом изменить имя пакета и версию основной ветки разработки для создания пакета Debian.
Для того, чтобы информация об имени пакета и номере версии эффективно обрабатывались такими популярными инструментами как команда aptitude, рекомендуется, чтобы длина имени пакета была равна 30 символам или была меньше; а общая длина версии и редакции была равна 14 символам или меньше. [11]
Для того, чтобы не возникали конфликты, видимое пользователю имя двоичного пакета не следует выбирать из числа распространённых слов.
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
Правило сравнения версий может быть представлены следующим образом:
Также имеются специальные правила для символов точки (.), плюса (+) и тильды (~). Они показаны ниже.
0.0 < 0.5 < 0.10 < 0.99 < 1 < 1.0~rc1 < 1.0 < 1.0+b1 < 1.0+nmu1 < 1.1 < 2.0
Один сложный случай возникает тогда, когда разработчики основной ветки выпускают hello-0.9.12-ReleaseCandidate-99.tar.gz как предварительный выпуск для hello-0.9.12.tar.gz. Вам следует гарантировать, что обновление пакета Debian будет происходить правильно, переименовав для этого архив с исходным кодом основной ветки в hello-0.9.12~rc99.tar.gz.
Неродной пакет Debian в формате «3.0 (quilt)» является самым обычным форматом пакетов Debian с исходным кодом. Файл debian/source/format должен содержать строку «3.0 (quilt)», что описывается в dpkg-source(1). Описанные выше процедуры создания пакетов и примеры используют этот формат.
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.
![[Caution]](images/caution.png)
|
Caution |
|---|---|
|
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.gz . 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:
If you need to create a native Debian package, create it in the “3.0 (native)” format using dpkg-source(1).
|
|
Tip |
|---|---|
|
Some people promote packaging even programs that have been written only for Debian in the non-native package format. The required tarball without debian/* files needs to be manually generated in advance before the standard workflow in Section 5.1, “Работа по созданию пакета”. [12] They claim that the use of non-native package format eases communication with the downstream distributions. |
|
|
Tip |
|---|---|
|
При использовании формата родных пкетов нужды заранее создавать tar-архив нет. Родной пакет может быть создан в том случае, если файл debian/source/format содержит строку «3.0 (native)», в файле debian/changelog указана версия без редакции Debian (1.0 вместо 1.0-1), а также в дереве исходного кода вызывается команда «dpkg-source -b .». Тогда создаётся tar-архив, содержащий исходный код. |
Сценарий debian/rules представляет собой исполняемый сценарий для сборки пакета Debian.
Сценарий debian/rules настраивает сборочную систему основной ветки (см. Section 5.18, “Системы сборки основой ветки”) не установку файлов в $(DESTDIR) и формирует архив созданных файлов в виде файла deb.
Путь $(DESTDIR) зависит от типа сборки.
The dh command from the debhelper package with help from its associated packages functions as the wrapper to the typical upstream build systems and offers us uniform access to them by supporting all the Debian policy stipulated targets of the debian/rules file.
|
|
Note |
|---|---|
|
Для пакетов, использующих debhelper и имеющих «compat >= 9», команда dh экспортирует флаги компилятора (CFLAGS, CXXFLAGS, FFLAGS, CPPFLAGS и LDFLAGS) со значениями, возвращаемыми командой dpkg-buildflags в том случае, если они не были установлены ранее. (Команда dh вызывает функцию set_buildflags, определённую в модуле Debian::Debhelper::Dh_Lib.) |
Благодаря абстракциям команды dh [13] соответствующий политике Debian файл debian/rules, поддерживающий все требуемые цели, можно написать так же просто как [14]:
Простой файл debian/rules:
#!/usr/bin/make -f
#export DH_VERBOSE = 1
%:
dh $@
По сути, эта команда dh работает как планировщик для вызовов всех требуемых команд dh_* в нужный момент.
|
|
Tip |
|---|---|
|
Установка «export DH_VERBOSE = 1» приводит к тому, что в выводе отражаются все команды, изменяющие файлы в сборочной системе. Кроме того, для некоторых систем сборки это включает режим создания более подробных журналов. |
Гибкая настройка сценария debian/rules осуществляется путём добавления соответствующих целей override_dh_* и их правил.
Всякий раз как требуется выполнить какую-то специальную операцию для определённой команды dh_foo, вызываемой командой dh, всякое автоматическое выполнение её может быть отменено путём добавления Makefile-цели override_dh_foo в файл debian/rules.
The build process may be customized via the upstream provided interface such as arguments to the standard source build system commands, such as:
If this is the case, you should add the override_dh_auto_build target and executing the “dh_auto_build -- arguments” command. This ensures passing arguments to the such build system after the default parameters that dh_auto_build usually passes.
|
|
Tip |
|---|---|
|
Please try not to execute the above build system commands directly if they are supported by the dh_auto_build command. |
The debmake command creates the initial template file taking advantage of the above simple debian/rules file example while adding some extra customizations for package hardening, etc. You need to know how underlying build systems work under the hood (see Section 5.18, “Системы сборки основой ветки”) to address their irregularities using package customization.
Некоторые определения переменных, которые могут оказаться полезными для debian/rules, можно найти в файлах в каталоге /usr/share/dpkg/. В частности:
If you wish to use some of these useful variables in debian/rules, copy relevant code to debian/rules or write a simpler alternative in it. Please keep debian/rules simple.
Например, можно добавить дополнительную опцию в CONFIGURE_FLAGS для архитектур linux-any, добавляя следующее в файл debian/rules:
DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS) ... ifeq ($(DEB_HOST_ARCH_OS),linux) CONFIGURE_FLAGS += --enable-wayland endif
|
|
Tip |
|---|---|
|
It was useful to include buildflags.mk in debian/rules to set the build flags such as CPPFLAGS, CFLAGS, LDFLAGS, etc. properly while honoring DEB_CFLAGS_MAINT_APPEND, DEB_BUILD_MAINT_OPTIONS, etc. for the debhelper “compat <= 8”. Now you should use the debhelper “compat >= 9”, should not include buildflags.mk without specific reasons, and should let the dh command set these build flags. |
См. Section 5.22, “Multiarch”, dpkg-architecture(1) и dpkg-buildflags(1).
Here are some recommendations to attain a reproducible build result.
Подробности можно найти на вики-странице ReproducibleBuilds.
Управляющий файл имя-исходного-кода_версия-исходного-кода_архитектура.buildinfo, создаваемый dpkg-genbuildinfo(1), содержит информацию о сборочном окружении. См. deb-buildinfo(5)
The debian/control file consists of blocks of meta data separated by a blank line. Each block of meta data defines the following in this order:
See Chapter 5 - Control files and their fields of the “Debian Policy Manual” for the definition of each meta data.
|
|
Note |
|---|---|
|
The debmake command sets the debian/control file with “Build-Depends: debhelper-compat (= 13)” to set the debhelper compatibility level. |
|
|
Tip |
|---|---|
|
If an existing package has lower than debhelper compatibility level 9, probably it’s time to update its packaging. |
For well behaving build systems, the split of a Debian binary package into small ones can be realized as follows.
С примерами можно ознакомиться в настоящем руководстве:
The debmake command with the -b option provides an intuitive and flexible method to create the initial template debian/control file defining the split of the Debian binary packages with following stanzas:
The debmake command also sets an appropriate set of substvars used in each pertinent dependency stanza.
Ниже приводится цитата соответствующей части страницы руководства debmake.
set the binary package specs by a comma separated list of binarypackage:type pairs, e.g., in the full form “foo:bin,foo-doc:doc,libfoo1:lib,libfoo-dev:dev” or in the short form, “-doc,libfoo1,libfoo-dev”.
Here, binarypackage is the binary package name, and the optional type is chosen from the following type values:
Пары значений в скобках, такие как (any, foreign), представляют собой значения служебных строк Architecture и Multi-Arch, устанавливаемые в файле debian/control.
Во многих случаях команда debmake довольно хорошо предсказывает значение поля тип, исходя из значения поля двоичныйпакет. Если тип не очевиден, то значением поля тип становится bin. Например, исходя из libfoo значением поля тип становится lib, а исходя из font-bar значением поля тип становится data, …
Если содержимое дерева исходного кода не совпадает с настройками поля тип, то команда debmake выводит предупреждение.
Ниже приводится несколько типичных сценариев разделения мультиархитектурного пакета для следующих примеров исходного кода основной ветки разработки, в которых используется команда debmake:
| двоичныйпакет | тип | Architecture: | Multi-Arch: | Содержимое пакета |
|---|---|---|---|---|
|
lib foo1 |
lib * |
any |
same |
разделяемая бибиотека, возможна совместная установка |
|
lib foo -dev |
dev * |
any |
same |
заголовочные файлы разделяемой библиотеки и проч., возможна совместная установка |
|
lib foo -tools |
bin * |
any |
foreign |
программы с поддержкой времени исполнения, совместная установка невозможна |
|
lib foo -doc |
doc * |
all |
foreign |
файлы документации разделяемой библиотеки |
|
bar |
bin * |
any |
foreign |
скомпилированный файлы программы, совместная устанвка невозможна |
|
bar -doc |
doc * |
all |
foreign |
файлы документации программы |
|
baz |
script |
all |
foreign |
файлы интерпретируемой программы |
Let’s consider that the upstream source tarball of the libfoo library is updated from libfoo-7.0.tar.gz to libfoo-8.0.tar.gz with a new SONAME major version which affects other packages.
Двоичный пакет библиотеки следует переименовать с libfoo7 в libfoo8, чтобы после загрузки пакета, созданного из на осно, в unstable все зависимые пакеты остались в рабочем состоянии.
![[Warning]](images/warning.png)
|
Warning |
|---|---|
|
If the binary library package isn’t renamed, many dependent packages in the unstable suite become broken just after the library upload even if a binNMU upload is requested. The binNMU may not happen immediately after the upload due to several reasons. |
Пакет -dev должен соответствовать следующим правилам именования:
Используйте имя пакета -dev без номера версии: libfoo-dev
В архиве может находится только одна версия пакета с исходным кодом библиотеки.
Используйте имена пакетов -dev с указанием версии: libfoo7-dev и libfoo8-dev
В архиве могут находится две версии пакетов с исходным кодом библиотеки.
|
|
Tip |
|---|---|
|
If the data encoding scheme changes (e.g., latin1 to utf-8), the same care as the API change needs to be taken. |
Кроме того, файл debian/control определяет зависимости пакета, в которых может исопльзоваться механизм подстановки переменных (substvar), который освобождает сопровождающих пакета от рутинной работы по отслеживанию большинства простых зависимостей пакета. См. deb-substvars(5).
The debmake command supports the following substvars:
Для разделяемых библиотек необходимые библиотеки обнаруживаются с помощью просто команды «objdump -p /путь/к/программе | grep NEEDED» и обрабатываются переменной подстановки shlib.
For Python and other interpreters, required modules found simply looking for lines with “import”, “use”, “require”, etc., are covered by the corresponding substvars.
Для остальных программ, не использующих собственные переменные подстановки, зависимости обрабатываются переменной misc.
Для программ командной оболочки POSIX нет простого способа определения зависимостей, поэтому их зависимости не обрабатываются никакой переменной.
Для библиотек и модулей, требующихся через механизм динамической загрузки, включая механизм GObject-интроспекция, нет простого способа определения зависимостей, поэтому их зависимости не обрабатываются никакой переменной.
A binNMU is a binary-only non-maintainer upload performed for library transitions etc. In a binNMU upload, only the “Architecture: any” packages are rebuilt with a suffixed version number (e.g. version 2.3.4-3 will become 2.3.4-3+b1). The “Architecture: all” packages are not built.
The dependency defined in the debian/control file among binary packages from the same source package should be safe for the binNMU. This needs attention if there are both “Architecture: any” and “Architecture: all” packages involved in it.
“Architecture: any” package: depends on “Architecture: any” foo package
“Architecture: any” package: depends on “Architecture: all” bar package
“Architecture: all” package: depends on “Architecture: any” baz package
The debian/changelog file records the Debian package history and defines the upstream package version and the Debian revision in its first line. The changes need to be documented in the specific, formal, and concise style.
Even if you are uploading your package by yourself, you must document all non-trivial user-visible changes such as:
If you are asking your sponsor to upload it, you should document changes more comprehensively, including all packaging related ones, to help reviewing your package.
Команда debmake создаёт изначальный шаблонный файл с версией основной ветки и редакцией Debian. С целью предотвращения случайной загрузки в архив Debian выбирается выпуск UNRELEASED.
The debchange command (alias dch) is commonly used to edit this.
|
|
Tip |
|---|---|
|
You can edit the debian/changelog file manually with any text editor as long as you follow the formatting convention used by the debchange command. |
|
|
Tip |
|---|---|
|
Строка с датой, используемая в файле debian/changelog, может быть создана вручную с помощью команды «LC_ALL=C date -R». |
Этот файл устанавливается командой dh_installchangelogs в каталог /usr/share/doc/двоичныйпакет под именем changelog.Debian.gz.
Журнал изменений основной ветки устанавливается в каталог /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.
After finishing your packaging and verifying its quality, please execute the “dch -r” command and save the finalized debian/changelog file with the distribution normally set to unstable. [15] If you are packaging for backports, security updates, LTS, etc., please use the appropriate distribution names instead.
Debian takes the copyright and license matters very seriously. The “Debian Policy Manual” enforces having a summary of them in the debian/copyright file in the package.
You should format it as a machine-readable debian/copyright file (DEP-5).
|
|
Caution |
|---|---|
|
Файл debian/copyright должен быть отсортирован таким образом, что наиболее общие шаблоны файлов были размещены в начале списка. См. Section 6.4, “debmake -k”. |
Команда debmake создаёт изначальный совместимый с DEP-5 шаблонный файл, сканируя все дерево исходного кода. Она использует специальную внутреннюю команду для проверки и классификации лицензий. [16]
Если команде debmake не была передана опция -P, то команда пропускает создаваемые автоматически файлы под разрешительными лицензиями.
|
|
Note |
|---|---|
|
Если при проверке лицензионной информации вы обнаружите какие-либо проблемы, то отправьте сообщение об ошибке в пакете debmake с проблемной частью текста, содержащего информацию об авторском праве и лицензии. |
|
|
Note |
|---|---|
|
The debmake command focuses on bunching up same copyright and license claims in detail to create template for debian/copyright. In order to do this within reasonable time, it only picks the first section which looks like copyright and license claims. So its license assignment may not be optimal. Please also use other tools such as licensecheck. |
|
|
Tip |
|---|---|
|
You are highly encouraged to check the license status with the licensecheck(1) command and, as needed, with your manual code review. |
Заплаты -p1 в каталоге debian/patches/ применяются в последовательности, определяемой в файле debian/patches/series, к дереву исходного кода основной ветки до запуска процесса сборки.
|
|
Note |
|---|---|
|
В родных пакетах Debian (см. Section 5.5, “Родной пакет Debian”) эти файлы не используются. |
Имеется несколько способов подготовки серии заплат -p1.
Команда diff
Примитивный, но универсальный метод
Команда dquilt
Команда «dpkg-source --commit»
Автоматическое создание заплат с помощью dpkg-buildpackage
The gbp pq command
The git-dpm command
Wherever these patches come from, it is a good idea to tag them with a DEP-3 compatible header.
|
|
Tip |
|---|---|
|
The dgit package offers an alternative git integration tool with the Debian package archive. |
Команда «dpkg-source -x» распаковывает пакет Debian с исходным кодом.
Обычно она же применяет заплаты из каталога debian/patches/ к дереву исходного кода и записывает состояние заплат в каталог .pc/.
Если вы хотите сохранить исходный код в неизменном состоянии (например, для использования в Section 5.15, “Запись в систему управления версиями (стандарт)”), то используйте опцию --skip-patches.
До появления опции --commit у команды dpkg-source в версии 1.16.1 для работы с заплатами -p1 из каталога debian/patches/ требовалась команда quilt (или её обёртка dquilt).
The patches should apply cleanly when using the dpkg-source command. Thus you can’t just copy the patches to the new packaging of the new upstream release if there are patch offsets, etc.
The dquilt command (see Section 3.4, “quilt”) is more forgiving. You can normalize the patches by the dquilt command.
$ while dquilt push; do dquilt refresh ; done $ dquilt pop -a
There is one advantage of using the dpkg-source command over the dquilt command. While the dquilt command cannot handle modified binary files automatically, the dpkg-source command detects modified binary files and lists them in the debian/source/include-binaries file to include them in the Debian tarball.
Some packages are signed by a GPG key.
Например, пакет GNU hello можно загрузить через HTTP по адресу https://ftp.gnu.org/gnu/hello/. Там содержится несколько файлов:
Выберем самую последнюю версию.
$ wget https://ftp.gnu.org/gnu/hello/hello-2.9.tar.gz ... $ wget https://ftp.gnu.org/gnu/hello/hello-2.9.tar.gz.sig ... $ gpg --verify hello-2.9.tar.gz.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 GPG 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.
$ 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 $ gpg --verify hello-2.9.tar.gz.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
|
|
Tip |
|---|---|
|
Если ваше сетевое окружение блокирует доступ к HKP-порту 11371, используйте «hkp://keyserver.ubuntu.com:80». |
After confirming the key ID 80EE4A00 is a trustworthy one, download its public key into the debian/upstream/signing-key.asc file.
$ gpg --armor --export 80EE4A00 >debian/upstream/signing-key.asc
Затем настройте файл debian/watch соответствующим образом.
version=4 pgpsigurlmangle=s/$/.sig/ https://ftp.gnu.org/gnu/hello/ hello-(\d[\d.]*)\.tar\.(?:gz|bz2|xz)
Теперь команда uscan будет выполнять проверку подлинности пакета с помощью его GPG-подписи.
Debian очень серьёзно относится к вопросу свободы ПО и руководствуется в этом DFSG.
Несоответствующие DFSG компоненты в tar-архиве исходного кода основной ветки можно легко удалить в том случае, когда для обновления пакета Debian используется команда uscan.
Запустите команду uscan для загрузки нового tar-архива основной ветки.
В каталог debian/ можно добавить дополнительные файлы настройки. Большинство из них используются для управления командами dh_*, предоставляемыми пакетом debhelper, но также имеются дополнительные файлы для команд dpkg-source, lintian и gbp.
|
|
Tip |
|---|---|
|
Наиболее свежий список доступных команд dh_* см. в debhelper(7). |
Файлы debian/двоичныйпакет.* предоставляют очень мощные средства для выбора путей установки файлов. С помощью этих файлов можно создать пакет даже из исходный кода основной ветки, неиспользующего какую-либо систему сборки. Пример см. в Section 8.2, “Без Makefile (командная оболочка, интерфейс командной оболочки)”.
The "-x[1234]" superscript notation that appears in the following list indicates the minimum value for the debmake -x option that will generate the associated template file. See Section 6.6, “debmake -x” or debmake(1) for details.
Ниже приводится отсортирванный по алфавиту список наиболее существенных файлов настройки.
Список устанавливаемых автодополнений bash.
The bash-completion package is required for both build
and user environments.
См. dh_bash-completion(1).
List files that should be removed but are not cleaned by the dh_auto_clean command.
См. dh_auto_clean(1) и dh_clean(1).
Previously, this set the debhelper compatibility level.
Now, use Build-Depends: debhelper-compat (=
13) in debian/control to specify the compatibility level.
См. «COMPATIBILITY LEVELS» в debhelper(8).
No need for this file now since all files in the etc/ directory are conffiles for recent “compat >= 3”.
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.
См. dh_installdeb(1).
Устанавливается в файл etc/cron/hourly/двоичныйпакет в двоичныйпакет.
См. dh_installcron(1) и cron(8).
Устанавливается в файл etc/cron/daily/двоичныйпакет в двоичныйпакет.
См. dh_installcron(1) и cron(8).
Устанавливается в файл etc/cron/weekly/двоичныйпакет в двоичныйпакет.
См. dh_installcron(1) и cron(8).
Устанавливается в файл etc/cron/monthly/двоичныйпакет в двоичныйпакет.
См. dh_installcron(1) и cron(8).
Устанавливается в файл etc/cron.d/двоичныйпакет в двоичныйпакет.
См. dh_installcron(1), cron(8) и crontab(5).
Если такой файл существует, то он устанавливается в etc/default/двоичныйпакет в двоичныйпакет.
См. dh_installinit(1).
Содержит список каталогов, которые должны быть созданы в двоичныйпакет.
См. dh_installdirs(1).
Это это не требуется, поскольку все команды dh_install* автоматически создают необходимые каталоги. Используйте этот файл только в том случае, если у вас возникают какие-либо затруднения.
Устанавливается как управляющий файл doc-base в двоичныйпакет.
См. dh_installdocs(1) и Руководство Debian по doc-base, предоставляемое пакетом doc-base.
Создержит список файлов документации для их установки в двоичныйпакет.
См. dh_installdocs(1).
Устанавливается в usr/lib/emacsen-common/packages/compat/двоичныйпакет в binarypackage.
См. dh_installemacsen(1).
Устанавливается в usr/lib/emacsen-common/packages/install/двоичныйпакет в двоичныйпакет.
См. dh_installemacsen(1).
Устанавливается в usr/lib/emacsen-common/packages/remove/двоичныйпакет в двоичныйпакет.
См. dh_installemacsen(1).
Устанавливается в usr/lib/emacsen-common/packages/startup/двоичныйпакет в двоичныйпакет.
См. dh_installemacsen(1).
Содержит список файлов или каталогов с примерами для их установки в usr/share/doc/двоичныйпакет/examples/ в двоичныйпакет.
См. dh_installexamples(1).
Если этот файл существует, то он используется как файл настройки для команды gbp.
См. gbp.conf(5), gbp(1) и git-buildpackage(1).
Содержит список info-файлов для их установки в двоичныйпакет.
См. dh_installinfo(1).
Устанавливается в etc/init.d/двоичныйнакет в двоичныйпакет.
См. dh_installinit(1).
Содержит список файлов, которые должны быть установлены, но не устанавливаются командой dh_auto_install.
См. dh_install(1) и dh_auto_install(1).
These are copyright file examples generated by the debmake command. Use these as the reference for making the copyright file.
Обязательно удалите эти файлы.
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).
Устанавливается в usr/share/lintian/overrides/двоичныйпакет в каталоге сборки пакета. Этот файл используется для блокировки ошибочных диагностических процедур lintian.
См. dh_lintian(1), lintian(1) и Руководство пользователя Lintian.
Команда debmake создаёт шаблонные файы страниц руководства. Переименуйте эти файлы соответствующим образом и обновите их содержимое.
Политика Debian требует, чтобы у каждой программы, утилиты и функции была связанная с ними страница руководства, входящая в состав того же пакета. Страницы руководства пишутся в формате nroff(1).
If you are new to making a manpage, use manpage.asciidoc or manpage.1 as the starting point.
Содержит список страниц руководства для их установки.
См. dh_installman(1).
Технический комитет в #741573 решил «В Debian следует соответствующим образом использовать файлы .desktop".
Файл меню Debian устанавливается в usr/share/menu/двоичныйпакет в двоичныйпакет.
Информацию о формате см. в menufile(5). См. dh_installmenu(1).
Устанавливается в usr/share/doc/двоичныйпакет/NEWS.Debian.
См. dh_installchangelogs(1).
Набор файлов заплат -p1, которые применяются к исходному коде основной ветки до запуска процесса сборки исходного кода.
См. dpkg-source(1), Section 3.4, “quilt” и Section 4.9, “Шаг 3 (альтернативный): изменение исходного кода основной ветки разработки”.
Команда debmake не создаёт файлы заплат.
Указанные сценарии сопровождаюшего устанавливаются в каталог DEBIAN.
В самих этих сценариях токен #DEBHELPER# заменяется на фрагменты кода, создаваемые другими командами debhelper.
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”.
Устанавливается в первый двоичный пакет, указанный в файле debian/control как usr/share/doc/двоичныйпакет/README.Debian.
См. dh_installdocs(1).
Этот файл содержит специальную информацию о пакете Debian.
Если этот файл существует, то он устанавливается в lib/systemd/system/двоичныйпакет.service в binarypackage.
См. dh_systemd_enable(1), dh_systemd_start(1) и dh_installinit(1).
Формат пакета Debian.
См. «SOURCE PACKAGE FORMATS» в dpkg-source(1).
Эти файлы не устанавливаются, но загружаются командой lintian и предоставляют отмены проверок для пакета с исходным кодом.
См. dh_lintian(1) и lintian(1).
The dpkg-source command uses this content as its options. Notable options are:
Этот файл не добавляется в создаваемый пакет с исходным кодом и предназначен скорее для добавления в систему управления версиями, используемую сопровождающим.
См. «FILE FORMATS» в dpkg-source(1).
Свободная текстовая форма, размещаемая в верхней части автоматически созданной заплаты.
Этот файл не добавляется в создаваемый пакет с исходным кодом и предназначен скорее для добавления в систему управления версиями, используемую сопровождающим.
+ См. «FILE FORMATS» в dpkg-source(1).
Файлы символов. Если эти файлы существуют, то они будут переданы для обработки и установки команде dpkg-gensymbols.
См. dh_makeshlibs(1) и Section 5.20.1, “Библиотека символов”..
Устанавливается в первый двоичный пакет, указанный в файле debian/control как usr/share/doc/двоичныйпакет/TODO.Debian.
См. dh_installdocs(1).
Если этот файл существует, то он устанавливается в usr/lib/tmpfiles.d/двоичныйпакет.conf в двоичныйпакет.
См. dh_systemd_enable(1), dh_systemd_start(1) и dh_installinit(1).
Если этот файл существует, то он устанавливается в etc/init/package.conf в каталог сборки пакета. (устарел)
См. dh_installinit(1) и Section 8.1, “Выборочное применение шаблонов”.
The control file for the uscan command to download the latest upstream version.
Этот управляющий файл можно настроить так, чтобы выполнялась проверка подлинности tar-архива с помощью его GPG-подписи (см. Section 5.11, “debian/upstream/signing-key.asc”).
См. Section 5.12, “debian/watch и критерии Debian по определению свободного ПО (DFSG)” и uscan(1).
Here are a few reminders for the above list.
Кратко резюмируем настройку пакета Debian.
All customization data for the Debian package resides in the debian/ directory. A simple example is given in Section 4.7, “Шаг 3: изменение шаблонных файлов”. Normally, this customization involves a combination of the following:
When these are not sufficient to make a good Debian package, modifications to the upstream source recorded as the -p1 patches in the debian/patches/ directory is deployed. These patches are applied in the sequence defined in the debian/patches/series file before building the package (see Section 5.10, “debian/patches/*”). Simple examples are given in Section 4.9, “Шаг 3 (альтернативный): изменение исходного кода основной ветки разработки”.
You should address the root cause of the Debian packaging problem by the least invasive way. The generated package shall be more robust for future upgrades in this way.
|
|
Note |
|---|---|
|
Send the patch addressing the root cause to the upstream maintainer if it is useful to the upstream. |
Typically, Git is used as the VCS to record the Debian packaging activity with the following branches.
ветка master
ветка upstream
|
|
Tip |
|---|---|
|
It’s a good idea to add to the .gitignore file the listing .pc. |
|
|
Tip |
|---|---|
|
Add unapply-patches and abort-on-upstream-changes lines to the debian/source/local-options file to keep the upstream portion unmodified. |
|
|
Tip |
|---|---|
|
Кроме того, вы можете отслеживать данные системы управления версиями основной ветки в отличной от upstream ветке, что облегчит выборочное использование заплат. |
Можно не сохранять заплаты -p1 для всех изменений основной ветки, свою работу над пакетом Debian можно хранить в следующих ветках.
ветка master
ветка upstream
Adding a few extra files in the debian/ directory enables you to do this.
$ tar -xvzf <package-version>.tar.gz $ ln -sf <package_version>.orig.tar.gz $ cd <package-version>/ ... hack...hack... $ echo "single-debian-patch" >> debian/source/local-options $ cat >debian/source/local-patch-header <<END This patch contains all the Debian-specific changes mixed together. To review them separately, please inspect the VCS history at https://git.debian.org/?=collab-maint/foo.git.
Let the dpkg-source command invoked by the Debian package build process (dpkg-buildpackage, debuild, …) generate the -p1 patch file debian/patches/debian-changes automatically.
|
|
Tip |
|---|---|
|
Этот подход может быть адаптирован для инструментов любых систем управления версиями. Поскольку в этом подходе происходит слияние всех изменений в объединённую заплату, постольку желательно сохранять данные системы управления версиями в открытом для всех виде. |
|
|
Tip |
|---|---|
|
Файлы debian/source/local-options и debian/source/local-patch-header следует сохранять в системе управления версиями. Они не входят в пакет Debian с исходным кодом. |
There are a few cases which cause the inclusion of undesirable contents in the generated Debian source package.
Обычно в Section 3.5, “devscripts” для команды dpkg-source устанавливаются опции -i и -I, что позволяет этого избежать. Опция -i предназначена для неродных пакетов, а опция -I — для родных пакетов. См. dpkg-source(1) и вывод команды «dpkg-source --help».
There are several methods to avoid inclusion of undesirable contents.
Проблема постороннего содержимого может быть исправлена путём удаления таких файлов в цели «debian/rules clean». Также это полезно и для файлов, создаваемых автоматически.
|
|
Note |
|---|---|
|
Цель «debian/rules clean» вызывается командой dpkg-buildpackage до выполнения команды «dpkg-source --build», поэтому команда «dpkg-source --build» игнорирует удалённые файлы. |
Проблема постороннего содержимого может быт исправлена путём восстановления дерева исходного кода путём внесения его в систему управления версиями до выполнения первой сборки.
Вы можете восстановить дерево исходного кода до выполнения второй сборки. Например:
$ git reset --hard $ git clean -dfx $ debuild
This works because the dpkg-source command ignores the contents of the typical VCS files in the source tree with the DEBUILD_DPKG_BUILDPACKAGE_OPTS setting in Section 3.5, “devscripts”.
|
|
Tip |
|---|---|
|
If the source tree is not managed by a VCS, you should run “git init; git add -A .; git commit” before the first build. |
This is for a non-native package.
Проблема посторонних изменений может быть исправлена путём игнорирования изменений, внесённых в часто дерева исходного кода, путём добавления в файл debian/source/options строки «extend-diff-ignore=…».
Для того, чтобы исключить файлы config.sub, config.guess и Makefile, добавьте следующее:
# Don't store changes on autogenerated files extend-diff-ignore = "(^|/)(config\.sub|config\.guess|Makefile)$"
|
|
Note |
|---|---|
|
Этот подход работает всегда, даже если вы не можете удалить файл. Поэтому он позволяет вам не делать резервную копию неизменённого файла только для того, чтобы восстановить его для выполнения следующей сборки. |
|
|
Tip |
|---|---|
|
Если используется файл debian/source/local-options, то можно скрыть эти настройки из создаваемого пакета с исходным кодом. Это может быть полезно в том случае, когда локальные нестандартные файлы системы управления версиями вмешиваются в процесс создания вашего пакета. |
This is for a native package.
Можно исклюить некоторые файлы в дереве исходного кода из создаваемого tar-архива с помощью настройки файлового шаблона, добавив строки вида «tar-ignore=…» в файлы debian/source/options или debian/source/local-options.
|
|
Note |
|---|---|
|
Если, например, пакету с исходным кодом для родного пакета требуются в качестве тестовых данных файлы с расширением .o, то использование Section 3.5, “devscripts” будет слишком агрессивным. Можно обойти эту проблему, удалив опцию -I из DEBUILD_DPKG_BUILDPACKAGE_OPTS в Section 3.5, “devscripts” и добавив строки вида «tar-ignore=…» в файл debian/source/local-options для каждого пакета. |
Системы сборки основной ветки предназначены для выполнения нескольких шагов, необходимых для установки созданных из набора файлов исходного кода двоичных файлов в систему.
Three typical build systems are described here. The situation of other
build systems are very similar to these since
debhelper(7) the does most of the work and helps you
build a Debian package.
|
|
Tip |
|---|---|
|
Before attempting to make a Debian package, you should become familiar with the upstream build system of the upstream source code and try to build it. |
Autotools (autoconf + automake) имеет 4 шага.
The upstream maintainer usually performs step 1 and builds the upstream tarball for distribution using the “make dist” command. (The generated tarball contains not only the pristine upstream VCS contents but also other generated files.)
The package maintainer needs to take care of steps 2 to 4 at least. This is realized by the “dh $@ --with autotools-dev” command used in the debian/rules file.
The package maintainer may wish to take care all steps 1 to 4. This is realized by the “dh $@ --with autoreconf” command used in the debian/rules file. This rebuilds all auto-generated files to the latest version and provides better support for porting to the newer architectures.
For compat level 10 or newer, the simple “dh $@” command without “--with autoreconf” option can take care all steps 1 to 4, too.
If you wish to learn more on Autotools, please see:
CMake имеет 4 шага.
The upstream tarball contains no auto-generated files and is generated by the tar command after step 1.
The package maintainer needs to take care of steps 2 to 4.
Если вы хотите изучить CMake, то обратитесь к следующей документации:
Meson has 4 steps.
The upstream tarball contains no auto-generated files and is generated by the tar command after step 1.
The package maintainer needs to take care of steps 2 to 4.
If you wish to learn more on the Meson, please see:
Python distutils имеет 3 шага.
The upstream maintainer usually performs step 1 and builds the upstream tarball for distribution using the “python3 setup.py sdist” command.
The package maintainer needs to take care of step 2. This is realized simply by the “dh $@” command used in the debian/rules file.
These days, most upstream maintainers of Python packages use setuptools with
wheel. Since setuptools is an extension of distutils, this step 2 works as
expected even if setup.py doesn’t explicitly uses
distutils.
If you wish to learn more on Python3, distutils, and setuptools, please see:
The Debian package is built with the debugging information but packaged into the binary package after stripping the debugging information as required by Chapter 10 - Files of the “Debian Policy Manual”.
См.
The debugging information is automatically packaged separately as the debug package using the dh_strip command with its default behavior. The name of such a debug package normally has the -dbgsym suffix.
If there were no -dbg packages defined in the debian/control file, no special care is needed for updating the package after the Stretch 9.0 release.
If there were -dbg packages defined in the debian/control file, following care is needed for updating the old package after the Stretch 9.0 release.
Packaging library software requires you to perform much more work than usual. Here are some reminders for packaging library software:
Before packaging shared library software, see:
Для получения исторических сведений обратитесь к следующей документации:
Спасение из ада зависимостей [17]
Руководство по созданию пакетов Debian с библиотеками [18]
The symbols support in dpkg introduced in Debian lenny (5.0, May 2009) helps us to manage the backward ABI compatibility of the library package with the same package name. The DEBIAN/symbols file in the binary package provides the minimal version associated with each symbol.
An oversimplified method for the library packaging is as follows.
Распакуйте старый файл DEBIAN/symbols ближайшего предыдущего двоичного пакета с помощью команды «dpkg-deb -e».
Скопируйте его в файл debian/двоичныйпакет.symbols.
Соберите двоичный пакет.
If the dpkg-gensymbols command warns about some new symbols:
If the dpkg-gensymbols command does not warn about new symbols:
Подробные сведения можно получить, обратившись к следующей справочной информации:
Также следует ознакомиться со следующей документацией:
|
|
Tip |
|---|---|
|
For C++ libraries and other cases where the tracking of symbols is problematic, follow 8.6.4 The shlibs system of the “Debian Policy Manual”, instead. Please make sure to erase the empty debian/binarypackage.symbols file generated by the debmake command. For this case, the DEBIAN/shlibs file is used. |
Когда вы создаёте новую версию пакета библиотеки, изменение которой влияет на другие пакеты, вам следует с помощью команды reportbug отправить сообщение об ошибке в псевдопакете release.debian.org с приложением ben-файла и подождать подтверждение загрузки от команды подготовки выпуска.
У команды подготовки выпуска имеется система отслеживания переходов. См. Transitions.
|
|
Caution |
|---|---|
|
Please make sure to rename binary packages as in Section 5.7.1.3, “Имя пакета библиотеки”. |
Пакет debconf позволяет нам настраивать пакеты в ходе их установки двуями основными способами:
интерактивно из меню-ориентированного интерфейса (dialog, gnome, kde, …)
Всё взаимодействие с пользователем в ходе установки пакета должны обрабатыватся системой debconf с помощью следующих файлов.
debian/binarypackage.config
debian/двоичныйпакет.template
сценарии настройка пакета
See dh_installdebconf(1), debconf(7), debconf-devel(7) and 3.9.1 Prompting in maintainer scripts in the “Debian Policy Manual”.
Multiarch support for cross-architecture installation of binary packages (particularly i386 and amd64, but also other combinations) in the dpkg and apt packages introduced in Debian wheezy (7.0, May 2013), demands that we pay extra attention to packaging.
Вам следует подробно изнакомиться со следующей справочной документацией:
Ubuntu вики (основная ветка разработки)
Debian вики (ситуация в Debian)
Мультиархитектурность включается с помощью значения <тройки> вида i386-linux-gnu или x86_64-linux-gnu в пути установки разделяемых библиотек вида /usr/lib/<тройка>/ и т. д.
The <triplet> value used in override_dh_* target scripts must be explicitly set in the debian/rules file by the maintainer. The <triplet> value is stored in the $(DEB_HOST_MULTIARCH) variable in the following debian/rules snippet example:
DEB_HOST_MULTIARCH = $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
...
override_dh_install:
mkdir -p package1/lib/$(DEB_HOST_MULTIARCH)
cp -dR tmp/lib/. package1/lib/$(DEB_HOST_MULTIARCH)
См.:
Debian policy requires following Filesystem Hierarchy Standard. Its /usr/lib : Libraries for programming and packages states "/usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts."
Debian policy makes an exception to the Filesystem Hierarchy Standard to use /usr/lib/<triplet>/ instead of /usr/lib<qual>/ (e.g., /lib32/ and /lib64/) to support a multiarch library.
Table 5.1. Опции путя мультиархитектурных библиотек
| Классический путь | Мультиархитектурный путь для 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/ |
Для пакетов на основе Autotools, в которых используется пакет debhelper с (compat>=9), установка этого пути выполняется автоматически с помощью команды dh_auto_configure.
При работе с другими пакетами, использующими неподдерживаемые системы сборки, вам следует вручную изменить путь установки указанным ниже способом.
All files installed simultaneously as the multiarch package to the same file path should have exactly the same file content. You must be careful with differences generated by the data byte order and by the compression algorithm.
|
|
Note |
|---|---|
|
The --libexecdir option of the ./configure command specifies the default path to install executable programs run by other programs rather than by users. Its Autotools default is /usr/libexec/ but its Debian non-multi-arch default is /usr/lib/. If such executables are a part of a "Multi-arch: foreign" package, a path such as /usr/lib/ or /usr/lib/packagename may be more desirable than /usr/lib/<triplet>/, which dh_auto_configure uses. The GNU Coding Standards: 7.2.5 Variables for Installation Directories has a description for libexecdir as "The definition of libexecdir is the same for all packages, so you should install your data in a subdirectory thereof. Most packages install their data under $(libexecdir)/package-name/ …". (It is always a good idea to follow GNU unless it conflicts with the Debian policy.) |
Файлы разделяемых библиотек, расположенные в каталогах по умолчанию, /usr/lib/ и /usr/lib/<тройка>/, загружаются автоматически.
For shared library files in another path, the GCC option -l must be set by the pkg-config command to make them load properly.
В мультиархитектурной системе Debian GCC по умолчанию включает и /usr/include/, и /usr/include/<тройка>/.
If the header file is not in those paths, the GCC option -I must be set by the pkg-config command to make "#include <foo.h>" work properly.
Table 5.2. Опции пути мультиархитектурного заголовочного файла
| Классический путь | Мультиархитектурный путь для i386 | Мультиархитектуный путь для amd64 |
|---|---|---|
|
/usr/include/ |
/usr/include/i386-linux-gnu/ |
/usr/include/x86_64-linux-gnu/ |
|
/usr/include/ имяпакета / |
/usr/include/i386-linux-gnu/ имяпакета / |
/usr/include/x86_64-linux-gnu/ имяпакета / |
|
/usr/lib/i386-linux-gnu/ имяпакета / |
/usr/lib/x86_64-linux-gnu/ имяпакета / |
The use of the /usr/lib/<triplet>/packagename/ path for the library files allows the upstream maintainer to use the same install script for the multiatch system with /usr/lib/<triplet> and the biarch system with /usr/lib<qual>/. [19]
The use of the file path containing packagename enables having more than 2 development libraries simultaneously installed on a system.
Программа pkg-config используется для получения информации об установленных в системе библиотеках. Она сохраняет свои параметры настройки в файле *.pc и используется для установки опций -I и -l для GCC.
Table 5.3. Опции пути к файлу *.pc
| Классический путь | Мультиархитектурный путь для i386 | Мультиархитектуный путь для amd64 |
|---|---|---|
|
/usr/lib/pkgconfig/ |
/usr/lib/i386-linux-gnu/pkgconfig/ |
/usr/lib/x86_64-linux-gnu/pkgconfig/ |
The compiler hardening support spreading for Debian jessie (8.0, TBA) demands that we pay extra attention to the packaging.
Вам следует подробно изнакомиться со следующей справочной документацией:
Команда debmake добавляет шаблонные комментарии в файл debian/rules, требующиеся для DEB_BUILD_MAINT_OPTIONS, DEB_CFLAGS_MAINT_APPEND и DEB_LDFLAGS_MAINT_APPEND (см. Chapter 4, Простой пример и dpkg-buildflags(1)).
DEP-8 defines the debian/tests/control file as the RFC822-style test metadata file for continuous integration (CI) of the Debian package.
It is used after building the binary packages from the source package containing this debian/tests/control file. When the autopkgtest command is run, the generated binary packages are installed and tested in the virtual environment according to this file.
See documents in the /usr/share/doc/autopkgtest/ directory and 4. autopkgtest: Automatic testing for packages of the “Ubuntu Packaging Guide”.
|
|
Note |
|---|---|
|
Testing of the binary packages during their building time can be accomodated
by |
Кроме того, в Debian существует ещё несколько других инструментов непрерывной интеграции.
Debian packaging practices are moving target. Please keep your eyes on DEP - Debian Enhancement Proposals.
Debian cares about supporting new ports or flavours. The new ports or flavours require bootstrapping operation for the cross-build of the initial minimal native-building system. In order to avoid build-dependency loops during bootstrapping, the build-dependency needs to be reduced using the profile builds feature.
|
|
Tip |
|---|---|
|
Если сборка базового пакета |
Поведение команды reportbug, используемой для отправки отчётов об ошибке в двоичномпакете, может быть настроено с помощью файлов в каталоге usr/share/bug/двоичныйпакет/.
Команда dh_bugfiles устанавливает эти файлы из шаблонных файлов в каталоге debian/.
debian/двоичныйпакет.bug-control → usr/share/bug/двоичныйпакет/control
debian/двоичныйпакет.bug-presubj → usr/share/bug/двоичныйпакет/presubj
debian/двоичныйпакет.bug-script → usr/share/bug/двоичныйпакет или usr/share/bug/двоичныйпакет/script
См. dh_bugfiles(1) и Возможности reportbug для разработчиков
|
|
Tip |
|---|---|
|
If you always remind the bug reporter of something or ask them about their situation, use these files to automate it. |
[11] Для более чем 90% пакетов длина имени пакета равна 24 символам или меньше этого числа; длина версии основной ветки равна 10 символам или меньше, а длина номера редакции Debian равна 3 символам или меньше.
[12] Use of the “debmake -t …” command or “git deborig -f HEAD” can help this workflow. See Section 6.2, “Snapshot upstream tarball (-d, -t)” and dgit-maint-merge(7).
[13] This simplicity is available since version 7 of the debhelper package. This guide assumes the use of debhelper version 13 or newer.
[14] Команда debmake создаёт несколько более сложный файл debian/rules. Тем не менее, это базовая часть.
[15] If you are using the vim editor, make sure to save this with the “:wq” command.
[16] Ранее для выполнения такой внутренней проверки использовалась команда licensecheck из пакета devscripts. Теперь же команда licensecheck предоставляется в виде отдельного пакета licensecheck и содержит множество улучшений.
[17] Этот документ был написан до появления файла symbols.
[18] The strong preference is to use the SONAME versioned -dev package names over the single -dev package name in Chapter 6. Development (-DEV) packages, which does not seem to be shared by the former ftp-master (Steve Langasek). This document was written before the introduction of the multiarch system and the symbols file.
[19] This path is compliant with the FHS. Filesystem Hierarchy Standard: /usr/lib : Libraries for programming and packages states "Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory."
| |
|
|
| Chapter 4. Простой пример |
|
Chapter 6. Опции debmake |