| Глава 9. Продвинутые темы работы над пакетом | ||
|---|---|---|
 |
 |
|
| Глава 9. Продвинутые темы работы над пакетом | ||
|---|---|---|
| |
|
|
Содержание
Let’s describe advanced topics on Debian packaging.
Let me oversimplify historical perspective of Debian packaging practices focused on the non-native packaging.
Debian was started in 1990s when upstream packages were available from public FTP sites such as Sunsite. In those early days, Debian packaging used Debian source format currently known as the Debian source format «1.0»:
The Debian source package ships a set of files for the Debian source package.
The modern Debian source format «3.0 (quilt)» was invented around 2008 (see «ProjectsDebSrc3.0»):
The Debian source package ships a set of files for the Debian source package.
package_version-revision.debian.tar.?z : tarball of debian/ for Debian modifications.
Most Debian packages adopted the Debian source formats «3.0 (quilt)» and «3.0 (native)».
Now, the git(1) is popular with upstream and Debian developers. The git and its associated tools are important part of the modern Debian packaging workflow. This modern workflow involving git will be mentioned later in «Глава 10, Packaging with git».
Current Debian packaging practices and their trends are moving target. See:
«Debian Trends» — Hints for «De facto standard» of Debian practices
You can also search entire Debian source code data by yourself, too.
«Debian Sources» — code search tool
Auto-generated files of the build system may be found in the released upstream tarball. These should be regenerated when Debian package is build. E.g.:
Some modern build system may be able to download required source codes and binary files from arbitrary remote hosts to satisfy build requirements. Don’t use this download feature. The official Debian package is required to be build only with packages listed in Build-Depends: of the debian/control file.
The dh_auto_test(1) command is a debhelper command that tries to automatically run the test suite provided by the upstream developer during the Debian package building process.
The autopkgtest(1) command can be used after the Debian package building process. It tests generated Debian binary packages in the virtual environment using the debian/tests/control RFC822-style metadata file as continuous integration (CI). See:
Кроме того, в Debian существует ещё несколько других инструментов непрерывной интеграции.
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 DEB_BUILD_PROFILES environment variable.
See Debian wiki: «BuildProfileSpec».
![[Подсказка]](images/tip.png) | Подсказка |
|---|---|
|
If a core package foo build depends on a package bar with deep build dependency chains but bar is only used in the test target in foo, you can safely mark the bar with <!nocheck> in the Build-depends of foo to avoid build loops. |
The compiler hardening support spreading for Debian jessie (8.0) demands that we pay extra attention to the packaging.
Вам следует подробно изнакомиться со следующей справочной документацией:
Команда debmake добавляет шаблонные комментарии в файл debian/rules, требующиеся для DEB_BUILD_MAINT_OPTIONS, DEB_CFLAGS_MAINT_APPEND и DEB_LDFLAGS_MAINT_APPEND (см. «Глава 5, Simple packaging» и dpkg-buildflags(1)).
Here are some recommendations to attain a reproducible build result.
Подробности можно найти на вики-странице «ReproducibleBuilds».
Управляющий файл имя-исходного-кода_версия-исходного-кода_архитектура.buildinfo, создаваемый dpkg-genbuildinfo(1), содержит информацию о сборочном окружении. См. deb-buildinfo(5)
Кроме того, файл debian/control определяет зависимости пакета, в которых может исопльзоваться «механизм подстановки переменных» (substvar), который освобождает сопровождающих пакета от рутинной работы по отслеживанию большинства простых зависимостей пакета. См. deb-substvars(5).
The debmake command supports the following substvars:
For the shared library, required libraries found simply by «objdump -p /path/to/program | grep NEEDED» are covered by the shlib substvar.
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-интроспекция», нет простого способа определения зависимостей, поэтому их зависимости не обрабатываются никакой переменной.
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 Library Packaging guide» [18]
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)
См.:
For well behaving build systems, the split of a Debian binary package into small ones can be realized as follows.
С примерами можно ознакомиться в настоящем руководстве:
An intuitive and flexible method to create the initial template debian/control file defining the split of the Debian binary packages is accommodated with the -b option. See «Раздел 15.2, «debmake -b»».
Ниже приводится несколько типичных сценариев разделения мультиархитектурного пакета для следующих примеров исходного кода основной ветки разработки, в которых используется команда debmake:
| двоичныйпакет | тип | Architecture: | Multi-Arch: | Содержимое пакета |
|---|---|---|---|---|
libfoo1 | lib* | any | same | разделяемая бибиотека, возможна совместная установка |
libfoo-dev | dev* | any | same | заголовочные файлы разделяемой библиотеки и проч., возможна совместная установка |
libfoo-tools | bin* | any | foreign | программы с поддержкой времени исполнения, совместная установка невозможна |
libfoo-doc | doc* | all | foreign | файлы документации разделяемой библиотеки |
bar | bin* | any | foreign | скомпилированный файлы программы, совместная устанвка невозможна |
bar-doc | doc* | all | foreign | файлы документации программы |
baz | script | all | foreign | файлы интерпретируемой программы |
Debian policy requires to comply with the «Filesystem Hierarchy Standard (FHS), version 3.0», with the exceptions noted in «File System Structure».
The most notable exception is the use of /usr/lib/<triplet>/ instead of /usr/lib<qual>/ (e.g., /lib32/ and /lib64/) to support a multiarch library.
Таблица 9.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.
Файлы разделяемых библиотек, расположенные в каталогах по умолчанию, /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.
Таблица 9.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.
Таблица 9.3. Опции пути к файлу *.pc
| Классический путь | Мультиархитектурный путь для i386 | Мультиархитектуный путь для amd64 |
|---|---|---|
/usr/lib/pkgconfig/ | /usr/lib/i386-linux-gnu/pkgconfig/ | /usr/lib/x86_64-linux-gnu/pkgconfig/ |
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.
Extract the old DEBIAN/symbols file of the immediate previous binary package with the «dpkg-deb -e» command.
Скопируйте его в файл debian/двоичныйпакет.symbols.
Соберите двоичный пакет.
If the dpkg-gensymbols command warns about some new symbols:
If the dpkg-gensymbols command does not warn about new symbols:
Подробные сведения можно получить, обратившись к следующей справочной информации:
Также следует ознакомиться со следующей документацией:
| Подсказка |
|---|---|
|
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. |
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 все зависимые пакеты остались в рабочем состоянии.
![[Предупреждение]](images/warning.png) | Предупреждение |
|---|---|
|
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
В архиве могут находится две версии пакетов с исходным кодом библиотеки.
| Подсказка |
|---|---|
|
If the data encoding scheme changes (e.g., latin1 to utf-8), the same care as the API change needs to be taken. |
When you package a new library package version which affects other packages, you must file a transition bug report against the release.debian.org pseudo package using the reportbug command with the ben file and wait for the approval for its upload from the Release Team.
У команды подготовки выпуска имеется «система отслеживания переходов». См. «Transitions».
![[Внимание]](images/caution.png) | Внимание |
|---|---|
|
Please make sure to rename binary packages as in «Раздел 9.17, «Library package name»». |
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 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.
Пакет debconf позволяет нам настраивать пакеты в ходе их установки двуями основными способами:
interactively from the menu interface (dialog, gnome, kde, …)
Всё взаимодействие с пользователем в ходе установки пакета должны обрабатыватся системой debconf с помощью следующих файлов.
debian/binarypackage.config
debian/двоичныйпакет.template
These debconf files are called by package configuration scripts in the binary Debian package
See dh_installdebconf(1), debconf(7), debconf-devel(7) and «3.9.1 Prompting in maintainer scripts» in the «Debian Policy Manual».
[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.»
| |
|
|
| Глава 8. More on packaging |
|
Глава 10. Packaging with git |