Differences between revisions 13 and 14
Revision 13 as of 2008-04-06 14:01:43
Size: 4846
Editor: FranklinPiat
Comment: linda is gone.
Revision 14 as of 2009-03-16 03:33:00
Size: 4850
Editor: anonymous
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 99: Line 99:
[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=373295 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 [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=373295 the support for deb-layout in Subversion properties] is not yet merged in svn-buildpackage, although a patch exists. [[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=373295|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 [[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=373295|the support for deb-layout in Subversion properties]] is not yet merged in svn-buildpackage, although a patch exists.

Normalised building process

Abstract

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

Benefits

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

Rules

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:/var/lib/gforge/chroot/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"
  • Enjoy!

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:

svn-builder=debuild
svn-reuse

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:

  • 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

Notes

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.