Пересборка двоичного пакета требуется при ряде обстоятельств. В некоторых случаях администратору нужна функциональность программы, для активации которой необходима компиляция из исходного кода с определенной опцией; в других программное обеспечение, упакованное в установленной версии Debian, недостаточно актуально. В последнем случае администратору обычно нужно собрать более свежий пакет, взятый из более новой версии Debian — например
Testing или даже
Unstable — чтобы новый пакет заработал в дистрибутиве
Stable; эта операция называется «бэкпортирование». Как обычно, прежде чем приступать к такой задаче, следует проверить, не был ли такой пакет уже создан, — для этого достаточно беглого взгляда на страницу данного пакета в Системе отслеживания пакетов Debian.
15.1.1. Получение исходного кода
Пересборка пакета Debian начинается с получения его исходного кода. Самый простой способ - использовать команду
apt-get source package-name. Эта команда требует наличия строки
deb-src в файле
/etc/apt/sources.list и актуальных индексных файлов (т.е.
apt-get update). Эти условия уже должны быть выполнены, если вы следовали инструкциям из главы, посвященной настройке APT (см.
Раздел 6.1, «Содержимое файла sources.list»). Однако обратите внимание, что вы будете загружать исходные пакеты из версии Debian, указанной в строке
deb-src.
Если вам нужна другая версия, вам может потребоваться загрузить её вручную с зеркала Debian или с веб-сайта. Это включает в себя получение двух или трёх файлов (с расширениями *.dsc - для Debian Source Control - *.tar.comp, и иногда *.diff.gz или *.debian.tar. comp - comp принимает одно из значений gz, bz2 или xz в зависимости от используемого средства сжатия), то выполните команду dpkg-source -x file.dsc. Если файл *.dsc доступен непосредственно по заданному URL, есть еще более простой способ получить его целиком с помощью команды dget URL. Эта команда (которую можно найти в пакете devscripts) получает файл *.dsc по указанному адресу, затем анализирует его содержимое и автоматически получает файл или файлы, на которые в нем есть ссылки. После того, как всё загружено, он проверяет целостность загруженных исходных пакетов с помощью dscverify, и извлекает исходный пакет (если не используется опция -d или --download-only). Если не указана опция -u, потребуется связка ключей Debian.
15.1.2. Внесение изменений
Для примера возьмём пакет samba.
$ apt source samba
Reading package lists... Done
NOTICE: 'samba' packaging is maintained in the 'Git' version control system at:
https://salsa.debian.org/samba-team/samba.git
Please use:
git clone https://salsa.debian.org/samba-team/samba.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 12.3 MB of source archives.
Get:1 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (dsc) [4,514 B]
Get:2 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (tar) [11.8 MB]
Get:3 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (diff) [468 kB]
Fetched 12.3 MB in 3s (4,582 kB/s)
dpkg-source: info: extracting samba in samba-4.13.13+dfsg
dpkg-source: info: unpacking samba_4.13.13+dfsg.orig.tar.xz
dpkg-source: info: unpacking samba_4.13.13+dfsg-1~deb11u3.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 07_private_lib
dpkg-source: info: applying bug_221618_precise-64bit-prototype.patch
dpkg-source: info: applying [...]
The source of the package is now available in a directory named after the source package and its version (samba-4.13.13+dfsg); this is where we'll work on our local changes.
The first thing to do is to change the package version number, so that the rebuilt packages can be distinguished from the original packages provided by Debian. Assuming the current version is
2:4.13.13+dfsg-1~deb11u3, we can create version
2:4.13.13+dfsg-1~deb11u3+falcot1, which clearly indicates the origin of the package. This makes the package version number higher than the one provided by Debian, so that the package will easily install as an update to the original package. Such a change is best effected with the
dch command (
Debian CHangelog) from the
devscripts package.
$ cd 4.13.13+dfsg-1~deb11u3
$ dch --local +falcot
Последняя команда вызывает текстовый редактор (
sensible-editor — это должен быть ваш любимый редактор, если он указан в переменной окружения
VISUAL или
EDITOR, а в противном случае редактор по умолчанию) для того, чтобы документировать изменения, внесенные данной пересборкой. Этот редактор показывает нам, что
dch действительно изменила файл
debian/changelog.
When a change in build options is required, the changes need to be made in debian/rules, which drives the steps in the package build process. In the simplest cases, the lines concerning the initial configuration (./configure …) or the actual build ($(MAKE) … or make … or cmake … or …) are easy to spot. If these commands are not explicitly called, they are probably a side effect of another explicit command, in which case please refer to their documentation to learn more about how to change the default behavior. With packages using dh, you might need to add an override for the dh_auto_configure or dh_auto_build commands (see their respective manual pages and debhelper(7) for explanations on how to achieve this).
В зависимости от локальных изменений в пакетах может потребоваться также обновление файла debian/control, который содержит описание создаваемых пакетов. В частности, этот файл содержит строки Build-Depends, контролирующие список зависимостей, которые должны быть удовлетворены на этапе сборки пакета. Они часто ссылаются на версии пакетов, содержащиеся в дистрибутиве, откуда взят исходный код, но которые могут быть недоступны в дистрибутиве, используемом для пересборки. Не существует автоматизированного способа определить, является ли зависимость реальной, или же она указана только с целью гарантировать выполнение сборки исключительно с последней версией библиотеки, — это единственный доступный способ заставить autobuilder использовать данную версию пакета во время сборки, из-за чего сопровождающие Debian часто используют строго версионированые сборочные зависимости.
Если вы точно знаете, что эти сборочные зависимости слишком строги, не стесняйтесь ослабить их локально. Чтение файлов, документирующих стандартный способ сборки программного обеспечения — эти файлы часто называют INSTALL — поможет выяснить соответствующие зависимости. В идеале все зависимости должны быть удовлетворены из дистрибутива, используемого для пересборки; в противном случае начинается рекурсивный процесс, в результате которого пакеты, упомянутые в поле Build-Depends, должны быть бэкпортированы раньше целевого пакета. Некоторые пакеты могут не требовать бэкпортирования, и их можно установить как есть в процессе сборки (ярким примером является debhelper). Обратите внимание, что процесс бэкпортирования может стать лавинообразным, если вы не будете осторожны. Поэтому бэкпорты должны быть сведены к абсолютному минимуму, насколько это возможно.
15.1.3. Запуск пересборки
Когда все необходимые изменения внесены в исходный код, мы можем запустить создание собственно двоичного пакета (файл .deb). Весь процесс управляется командой dpkg-buildpackage.
Пример 15.1. Пересборка пакета
$ dpkg-buildpackage -us -uc
[...]
The previous command can fail if the
Build-Depends field has not been updated, or if the related packages are not installed. In such a case, it is possible to overrule this check by passing the
-d option to
dpkg-buildpackage. However, explicitly ignoring these dependencies runs the risk of the build process failing at a later stage. Worse, the package may seem to build correctly but fail to run properly: some programs automatically disable some of their features when a required library is not available at build time. The switch can still be very useful if you only want to create a source package, which is supposed to be passed to clean build environments as described in
QUICK LOOK Building packages in chrooted and virtual environments.
The other options used in the above example make sure that neither the source package's .dsc (-us) nor the produced .changes file (-uc) get signed with the package builder's cryptographic key after the asuccessful build.
More often than not, Debian developers use a higher-level program such as debuild; this runs dpkg-buildpackage as usual, but it also adds an invocation of a program that runs many checks to validate the generated package against the Debian policy. This script also cleans up the environment so that local environment variables do not “pollute” the package build. The debuild command is one of the tools in the devscripts suite, which share some consistency and configuration to make the maintainers' task easier.
