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://svn.debian.org/svn/pkg-games/trunk/game cd game svn-buildpackage
Also, building older releases is as simple as building the trunk revision, just change the subversion URI:
svn co svn://svn.debian.org/svn/pkg-games/tags/game/1.02-1 cd 1.02-1 svn-buildpackage
There are a lot of benefits from this:
lower entry barrier for new-commers (is simple enough that we could ask a user to do it )
- automated builds, checks - lintian, piuparts - can be performed (could be triggered autoamtically after each tagging of packages or even after each commit)
- no hidden information, private orig tarballs and simillar things
- build errors can be spotted very early
- new packages can be tested faster by ourselves since build results could be preserved
Here are the rules that must respected in order to achive a standard build process:
- upload the orig tarball for every package that you maintain to the pkg-games' canonical place for them
scp $GAME_$VERSION.orig.tar.gz alioth.debian.org:/home/groups/pkg-games/htdocs/tarballs/
- set the property svn-bp:origUrl of the debian folder of the package to point to the corresponding orig tarball
svn co svn+ssh://svn.debian.org/svn/pkg-games/packages/trunk/$GAME cd $GAME svn propset svn-bp:origUrl "http://pkg-games.alioth.debian.org/tarballs/$GAME_$VERSION.orig.tar.gz" debian svn ci -N debian -m "origUrl property set for $GAME $VERSION"
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.
Before implementing this some blocking points need to be removed:
- all packages should have their orig tarballs present on our webspace (exceptions can be made for those that reached the archive already)
After removing the blocking points, it will be possible to build in a simple manner like the above, if a few rules are respected:
- all packages have the svn-bp:origUrl property set (or the remote origDir set) - some of the packages already have the svn-bp:origUrl property set
- no build dependencies are outside of the official archive
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://svn.debian.org/svn/pkg-games/packages/trunk/glest 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.