Building packages
In the source package chapter we learned what is inside a source.
This chapter explains how to build a package. All building is done with tools around dpkg-buildpackage, for example there is debuild.
Build requirements
You can install the build dependencies via APT. This is helpful when you need to re-build a package or want to make small modifications.
sudo apt build-dep icingaweb2
When there are different dependencies in the next package version, you either need to install them manually, or use advanced helpers like pbuilder-satisfydepends. (WARNING: This is meant for chroot builds)
Build a package
Since we already have a source tree we can just build the current package:
debuild
Every build cleans up the build tree to start the build from scratch.
Lab: Let's run the build and check the build log about what is happening.
Bonus: Add export DH_VERBOSE=1
to the top of rules
to have a detailed log
Build output
After the build certain files are created in the parent directory.
<package>*_<version>.deb
- the Debian binary packages- Files as describes in Source Package
<source>_<version>_<arch>.changes
Metadata for the finished build and upload<source>_<version>_<arch>.build
Log of the build<source>_<version>_<arch>.buildinfo
Extended metadata for the build
Inspecting build
Inside the source tree you will find the typical build artifacts and binaries like in a normal sourcecode build.
But also inside the debian/
directory, you will find new files and directories:
tmp/
- temporary file tree installed bydh_auto_install
<package>/
- file tree for every package<package>.substvars
- replacement variables forcontrol
<package>.debhelper.log
- log which debhelper tools have been run for this package
Also the built binary package files can be inspected and even extracted without actually installing them by using dpkg-deb.
dpkg-deb -c icingacli_2.6.1-1_all.deb
dpkg-deb -I icingacli_2.6.1-1_all.deb
mkdir test/
dpkg-deb -R icingacli_2.6.1-1_all.deb test/
Lab: Browse the directories under debian/
and have a look inside the built binaries
Update changelog
After changing packaging you always have to record that in changelog
. It not only defines the version, but should
contain useful short information about what was done.
Every changelog entry contains:
- Source packages
- Version
- Target distribution (you will mostly see unstable and experimental here - UNRELEASED is for an incomplete changelog)
- Update priority (used for repository management in Debian)
- List of changes in text form
- Line signature with timestamp, developer name and e-mail
To make this simple tools like dch and gbp-dch help.
dch # spawns an editor
dch -a "I changed feature X" # adds a new line to the current entry
dch -v 1.1.0-1 "Updated to 1.1.0" # make a new release version
You can always manually edit the file, as long as you keep the basic format.
Signing and changes
When a build is finished the .dsc
and .changes
files will be signed by a developer. Those file contains checksums
for all included files.
With upload tools like dput-ng the changes and all dependent files can be uploaded to a repository.
Most repositories build trust on the signature and will apply a certain release mechanism.