[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]

Debian New Maintainers' Guide
Chapter 6 - Building the package

We should now be ready to build the package.

6.1 Complete (re)build

In order to properly make complete (re)build of a package, you have to ensure to install

Then you issue the following command in the source directory: 

     $ dpkg-buildpackage

This will do everything to make full binary and source packages for you. It will:

The only input that will be required of you is your GPG secret pass phrase, twice.

After all this is done, you will see the following files in the directory above (~/gentoo):

The long strings of numbers in the .dsc and .changes files are MD5/SHA1/SHA256 checksums for the files mentioned. A person downloading your files can test them with md5sum(1), sha1sum(1), or sha256sum(1) and if the numbers don't match, they'll know the file is corrupt or has been tampered with.

6.2 Autobuilder

Debian supports many ports with the autobuilder network running buildd daemons on many different architecture computers. Although you do not need to do this by yourself, you should be aware of what will happen on your packages. Let's look into roughly how your packages are rebuild for many different architectures by them. [41]

For "Architecture: any" packages, the autobuilder system rebuild them. It ensures to install

Then it issues the following command in the source directory: 

     $ dpkg-buildpackage -B

This will do everything to make architecture dependent binary packages on another architecture. It will:

This is why you see your package for other architectures.

Although packages listed in the Build-Depends-indep: field are required to be installed for the normal packaging by us (see Complete (re)build, Section 6.1), they are not required to be installed for the autobuilder system since it build only architecture dependent binary packages. [42] This difference between normal packaging and autobuilder situation dictates whether you record such required packages in the Build-Depends: or Build-Depends-indep: fields of the debian/control file (see control file, Section 4.1).

6.3 Including orig.tar.gz for upload

When you first upload the package to the archive, you need to include the original orig.tar.gz source. If the last changelog entry is not the first one for the given upstream version, you must provide dpkg-buildpackage command with the "-sa" option. On the other hand, the "-sd" option will force to exclude the original orig.tar.gz source.

6.4 debuild command

You can automate package build process of the dpkg-buildpackage command further with the debuild command. See debuild(1).

Customization of the debuild command can be done through /etc/devscripts.conf or ~/.devscripts. I would suggest at least following items: 

     DEBSIGN_KEYID="Your_GPG_keyID"
     DEBUILD_LINTIAN=yes
     DEBUILD_LINTIAN_OPTS="-i -I --show-overrides"

With these, packages are signed by your specified GPG key ID (good for sponsoring packages) and checked by the lintian command in details.

Cleaning source and rebuilding package from a user account is as simple as: 

     $ debuild

Please note that the dpkg-buildpackage option "-sa" to include the original orig.tar.gz source can be specified as: 

     $ debuild -sa

You can clean source tree as simple as: 

     $ debuild clean

6.5 pbuilder package

For a clean room (chroot) build environment to verify the build dependencies, the pbuilder package is very useful. [43] This ensures a clean build from the source under the sid auto-builder for different architectures and avoids the severity serious FTBFS (Fails To Build From Source) bug which is always in the RC (release critical) category. See http://buildd.debian.org/ for more on the Debian package auto-builder.

Let's customize the pbuilder package by the following.

This will allow you to sign generated packages with your secret GPG key in the ~/.gnupg/ directory.

Let's then initialize the local pbuilder chroot system first as follows. 

     $ sudo pbuilder create

If you already have the completed source packages, issue the following commands in the directory where the foo.orig.tar.gz, foo.debian.tar.gz, and foo.dsc files exist to update the local pbuilder chroot system and to build binary packages in it. 

     $ sudo pbuilder --update
     $ sudo pbuilder --build foo.dsc

Please note that the dpkg-buildpackage option "-sa" to include the original orig.tar.gz source can be specified as: 

     $ sudo pbuilder --build --debbuildopts "-sa" foo.dsc

The newly built packages will be located in /var/cache/pbuilder/result/ with non-root ownership.

If you already have the updated source tree without generating the matching source packages, issue the following commands in the source directory where the debian directory exists, instead. 

     $ sudo pbuilder --update
     $ pdebuild

Please note that the dpkg-buildpackage option "-sa" to include the original orig.tar.gz source can be specified as: 

     $ pdebuild --debbuildopts "-sa"

You can log into its chroot environment with the "pbuilder --login --save-after-login" command and configure it as you wish. This environment can be saved by leaving its shell prompt with ^D (Control-D).

The latest version of the lintian command can be executed in the chroot environment using the hook script configured as follows. [44] 

     $ cat > /var/cache/pbuilder/hooks/B90lintian <<EOF
     #!/bin/sh
     set -e
     install_packages() {
         apt-get -y --force-yes install "$@"
         }
     install_packages lintian
     echo "+++ lintian output +++"
     su -c "lintian -i -I --show-overrides /tmp/buildd/*.changes" - pbuilder
     # use this version if you don't want lintian to fail the build
     #su -c "lintian -i -I --show-overrides /tmp/buildd/*.changes; :" - pbuilder
     echo "+++ end of lintian output +++"
     EOF

You need to have access to the latest sid environment to build packages properly for sid. In reality, sid may be experiencing issues which makes it not desirable for you to migrate your whole system. The pbuilder package can help you to cope with this kind of situation.

You may need to update your stable packages after their release for stable-proposed-updates, stable/updates, etc. [45] For such occasions, "I am running sid system" is not good enough excuse not to update them promptly. The pbuilder package can help you to access environments of almost any Debian derivative distributions of the same CPU architecture.

See http://www.netfort.gr.jp/~dancer/software/pbuilder.html, pdebuild(1), pbuilderrc(5), and pbuilder(8).

6.6 git-buildpackage command and similars

If your upstream uses the source code management system (VCS) to maintain their code, you should consider to use them. That makes merging and cherry-picking upstream patches much easier. There are several specialized wrapper script packages for the Debian package building for each VCS.

These packages offer more elegant working environment than manual use of the quilt commands for advanced audiences to automate building of packages. I will not explain them in this tutorial. [46]

6.7 Quick rebuild

With a large package, you may not want to rebuild from scratch every time while you tune details in debian/rules. For testing purposes, you can make a .deb file without rebuilding the upstream sources like this [47]: 

     $ fakeroot debian/rules binary

Or, simply as following to see if it build or not. 

     $ fakeroot debian/rules build

Once you are finished with your tuning, remember to rebuild following the proper procedure. You may not be able to upload correctly if you try to upload .deb files built this way.

[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]

Debian New Maintainers' Guide

version 1.2.19, 2010-05-31 13:48:35 UTC

Josip Rodin joy-mg@debian.org