Normalised building process


This page gathers up the way all our packages should be built and what rules they have to respect in order to achieve this.

It is desirable that building any package from our repository to be as simple as typing:

svn co svn://
cd game

Also, building older releases is as simple as building the trunk revision, just change the subversion URI:

svn co svn://
cd 1.02-1


There are a lot of benefits from this:


Here are the rules that must respected in order to achive a standard build process:

scp $GAME_$VERSION.orig.tar.gz

svn co svn+ssh://$GAME
cd $GAME
svn propset svn-bp:origUrl "$GAME_$VERSION.orig.tar.gz" debian
svn ci -N debian -m "origUrl property set for $GAME $VERSION"

Checking diffs

Often, an inadequate clean target or other mistake will result in files unintentionally being included in a source package's diff. The following configuration changes make it easy to check the diff after every successful build.

Put the following in ~/.devscripts:

DEBUILD_POST_DPKG_BUILDPACKAGE_HOOK="zcat %p_%v.diff.gz | lsdiff"

This tells debuild to list the files in the diff after any successful build.

The next bit goes in ~/.svn-buildpackage.conf, for users of svn-buildpackage:


This tells svn-buildpackage to use debuild, so that this hook is still run when using svn-buildpackage, and to preserve the build directory in between builds, so that the clean target can be tested to work between builds, and so that one can check that packages won't FTBFS the second time they are built.

Current status

Before implementing this some blocking points need to be removed:

After removing the blocking points, it will be possible to build in a simple manner like the above, if a few rules are respected:

Some packages have currently set the svn-bp:origUrl property and is possible to do a 3 step build. Such packages are Glest and Oolite:

svn co svn://
cd glest
svn-buildpackage --svn-override=origDir='..'

Note: many packages have the svn-deblayout specifying the origDir as "../tarball", this should be clarified and enforced in order to achieve a stadard build process


Build dependencies outside of the official archive could be specified, but some tool should be written/found or svn-buildpackage should be modified to support it. This point was never a concern for us (except the enet library), but usually build dependencies should be in the archive anyway, so this could be just a transitory state.

Subversion properties are a really good way of specifying things like svn-bp:origUrl or svn-buildackage information, since most of these are directly connected to the version that is build. Tagging or branching a directory with a Subversion property will preserve the information in the derived copy, while trunk can advance, since after branching/tagging the directories become two different items, each with its own set of properties. Unfortunately the support for deb-layout in Subversion properties is not yet merged in svn-buildpackage, although a patch exists.

Your help is appreciated with any of the issues specified.