At this point, you can either go on to build the package, or you can stop, and the release will remain ready for when you do want to build.
Version numbering is interesting in Debian, because you need to keep track of at least two things:
- The upstream version number.
- The Debian revision number, which is essentially the version number for the debian directory contents.
But, you may also have to add other things:
- Debian derivatives (like Ubuntu) add their own suffix and number, like ubuntu1 or ubuntu2.
- If you are building something outside of the normal process, such as a backport (a newer version packaged for a production Debian release) or a test build, you need an additional suffix for that, normally a tilde character followed by something.
When constructing the package version number, there are two rules, and one very important exception to remember:
- Version numbers are evaluated in “parts”, where each “part” is non-digit characters followed by digit characters. So, in the version number
2.1.2-1, the parts are
- Within a part, first the non-numeric portion is compared (using an ASCII sort), and if equal, the numeric portion is compared (using a numeric sort).
- In Debian version numbers, the tilde character (
~) sorts before everything else, including the empty string.
Because of that exception, if you have a test build (like
2.1.2-1~testFoo+1) or a backport (
2.1.2-1~bpo8+1), Debian will treat those versions as being older than a released version (like
More information is available in the Debian Policy Manual, sections 3.2 and 5.6.12.
Given all of the above, here are recommended version numbers to use:
- Backports (no code changes) for Debian should use the form
VERSION-1~sbp8+1, where the
8 is the version number of the Debian release (Debian jessie is version 8).
- Backports (no code changes) for Ubuntu should use the form
16.04 is the Ubuntu version.
- If we are making actual code changes, we should use a form like
VERSION-1stanford1. We should then try to get those code changes applied upstream.
We use a different form for code changes because we want that to remain newer than anything that comes in through Debian/Ubuntu upstream (lest we lose our changes in an upgrade). Since backports don’t have code changes, they are lower-priority.
Building the package
Once you have a release tagged and pushed, it is time to build the package. Before you start, you have to make a choice: You can either build the package on your own system, or you can use the Debian build service. Either way, the build products are the same.
Building on your own system
The easiest way to build Singularity packages is on a system that you’ve already got. On the one hand, you don’t have to maintain a separate infrastructure! However, you will only build for the release that you are running on that system. So, if you’re running Debian wheezy, you’ll only be able to build packages for Debian wheezy.
The other downside is that you’ll have to install all of the build dependencies system-wide. However, that’s not a big problem here, because Singularity’s needs are very simple. There are four packages (plus all of their dependencies) that need to be installed:
build-essential is a single package that installs (via dependencies) all of essential things that are required for building Debian packages.
debhelper is a suite of scripts that help to automate the Debian package-building process. Almost all of the steps in making a package, such as generating the list of changes, are orchestrated by debhelper. (Singularity uses debhelper, which is why this is required.)
dh-autoreconf is an optional debhelper component that ensures autoreconf is run before the software’s configure script. This package also has the various autotools (
automake, etc.) as dependencies, so we can be sure they are also installed. (Singularity uses
dh-autoreconf, which is why this is required.)
- Since we are getting everything from a Git repository, you’ll need to install git.
You only have to do this the first time you build on this system.