Debian package building scripts consist of several inter-related tools, which are documented well with manpages, but not in the code itself.
Should you have some free time I urge you to take a peak at the source code of dpkg-buildpackage, debsign, and debuild. They work. They work well, but they're not shining examples of clear code are they?
Given that they work, and that they are complex I'm not sure I'm interested in improving things, but I do have a personal desire to run something like:
debuild -sa --output=/tmp/results/
What would that do? Instead of placing the resulting package in the parent directory, which is what we have by default, it would place them in the named directory.
However looking over the code I see that there are too many places where "../$file" is hardwired. e.g. Take a look at dpkg-buildpackage and you see:
my $chg = "../$pva.changes";
..
open OUT, '>', $chg or syserr(_g('write changes file'));
If you change that to the simple code below it works - but suddenly debsign fails to find the file:
my $dir = $ENV{'OUTPUT'} || "..";
my $chg = $dir . "/" . $pva . ".changes";
Ugh.
I guess I can come up with some hack to index files in the parent, run a build process, and move the only new files into place. But that's sleazy at best, and still doesn't solve the problem that we have tools which we rely upon which are .. unfriendly to changes.
I thought I could handle this via:
debuild \ --post-dpkg-buildpackage-hook="move-changes-contents /tmp/output/ ../%p_%v_`dpkg-architecture -qDEB_HOST_ARCH`.changes" \ --no-tgz-check -sa -us -uc(Here "move-changes-contents" would read the given .changes file and move both it and the contents listed in it to the specified directory.)
Unfortunately %v corresponds to the package version - which isn't the same as the version in the .changes filename. (i.e. epochs are stripped out.)
ObQuote: I am the servant of the power behind the Nothing - The Neverending Story.
Tags: debuild, dpkg, tools 4 comments