C, debian, docker, linux, programming

Debian build environment in a docker container

Last post, I shared a docker container for compilation in C with ccache and colorgcc included. This time, we will extend that base container for development and packaging of Debian packages.

Not only it is handy to have the environment configured and packaged, but also opens some oportunities for optimization given the nature of docker, its catching overlays and its volumes.

Finally, it makes it easy to start developing Debian packages from another distribution, such as Arch Linux.


  • GCC 6
  • Debian package development tools: lintian, quilt, debuild, dh-make, fakeroot
  • quilt configured for debian patching
  • ccache for fast recompilation. Included in debuild and dpkg-buildpackage calls
  • eatmydata for faster compilation times
  • Only 192 MB uncompressed extra layer, totalling 435 MB for the whole container

If you are reading this post, you probably do not need an explanation about those tools. Look at the references section otherwise.

If you are wondering how this compares to sbuild and pbuilder, this approach is really very similar. The idea is the same: have another clean and isolated environment where compilation takes place. This solves several problems:

  • You can build for a different version of Debian, such as unstable or testing, without messing up your system with packages from those.
  • You can be sure that the dependencies are right, as the environment is minimal.

Well, docker containers can be used as a chroot in steroids, and can be regarded as an evolution of the concept using modern kernel features such as cgroups and namespaces.

Another nice benefit: it is very simple to manage docker containers. You can pull them, push them, export them and save them.

Last, a huge benefit at least for me personally is to be able to work from another Linux distribution, such as Arch.


Log into the development environment

docker run --rm -v "/workdir/path:/src" -ti ownyourbits/debiandev

We can now use the standard tools, the working directory ( /workdir/path in this example ) is an external folder accessible from the container, where you can do apt-get source  and retrieve the .deb files.

Example: cross-compile QEMU for ARM64

In my experience, not all packages are configured well enough to support cross-compilation. Specially big packages tend to fail when it comes to the build-dep  step. I found this nice exception in this post.

Example: package and tweak PHP, with CCACHE cache already populated

I like to use this container as a base for each specific project. This way, I can take advantage of the catching layers of docker to speed up the process, and at the same time I end up with the building instructions compiled in the Dockerfile.

If you decide to use a docker volume, you can always remove it if you want to start from zero. This has the benefit that upon running the container, /src will be populated with the results and cache from the Dockerfile step again. A real time saver!









Author: nachoparker

Humbly sharing things that I find useful [ github dockerhub ]

Leave a Reply

Your email address will not be published. Required fields are marked *