With buildbox, package builds were supposed to be:Īutomated. Later, this project became known as buildbox. The milestone's goal was to develop a new and better build system based on our past experience. In May 2014, I had the chance to start working on what we called the 'Packaging 2.0' milestone. To sum it up, buildhost02 was what is called a unique snowflake. Moreover, as building usually involves installing multiple dependencies, the host was getting more and more contaminated over time. Our build server, buildhost02, was hard to understand and modify, and setting up another server with the same functionality was quite a hassle (despite its name ending in '02,' there was no other server should things go wrong).

The list of problems makes it obvious that this build system wasn't going to last forever.

Apart from a loose collection of shell scripts, there was no unified way of creating packages, let alone a default location for the sources they stemmed from. And worst of all, we sometimes didn't know how a package was created. This process had several drawbacks: It was often hard to figure out who built a particular package or why it was built in the first place. In order to create packages back then, engineers had to log into a dedicated build server, aptly named buildhost02, and then run a couple of shell commands as a special 'buildcontroller' user. So being able to build and maintain Debian packages has always been important to us. In addition, we want to distribute our own tools as. However, if the bundled software is outdated, we still need to recompile a newer version ourselves. Debian itself already comes with thousands of packages ready to be installed. We've relied on the Debian operating system to power our servers from day one. When I started working at Jimdo in 2013, we had our own share of problems building Debian packages.

In this article I will tell you the story behind a build system for Debian packages I developed at Jimdo that addresses many pain points we faced over the years. There are many things that can, and initially will, go wrong.įortunately, the right mix of automation and virtualization can make a big difference. deb package, chances are you were either overwhelmed by the sheer number of available build tools and file formats or you messed up your system in an attempt to satisfy all of the package's dependencies. If you've ever tried to turn some software into a.

Building Debian packages isn't always fun.

Docker deb