Trimming bzr package size

[Stephen J. Turnbull]

John Arbash Meinel writes:

 > > I've tried to split tests out of bzrlib. This is hard but possible.
 > > But without nested trees it's not very good idea, IMO.
 > 
 > I think that comes down to creating reasonable packaging scripts, rather
 > than trying to do it as part of bzr itself.

I don't know what's Debian-ly correct, but for XEmacs I just use tar's
exclude facility.  I build a list of files that belong in each
subsidary tarball (in XEmacs that's the Info docs and the compiled
Lisp, and the source) using find, there's a standard list of excludes
like CVS (and now .hg), and then

make distclean
cd ..
tar -X $INFO_FILES -X $ELC_FILES -X $JUNK czf xemacs-src.tar.gz xemacs-$VERSION
tar -X $JUNK czf xemacs-info.tar.gz $INFO_FILES
tar -X $JUNK czf xemacs-elc.tar.gz $ELC_FILES
tar -X $JUNK czf xemacs.tar.gz $TOPDIR

Works fine.  I don't do Windows, don't know how you'd do this for
Windows (but that doesn't seem to be relevant here anyway).

 > Though I also thought that part of building packages was to run the
 > program's test suite, and I'm not sure how that works with ripping out
 > the test suite...

Of course I do a build ("guaranteed to have built on the release
engineer's host ... YMMV") and test.

You need to make sure the distclean target catches all test build
products (including intermediate products that might fail to get
cleaned up if a test crashes ... I know you'd *never* release if the
test were failing, but somehow the penultimate mess seems to get
grandfathered into the ultimate release, with red faces all around).

I'm pretty sure that there must be standard ways of doing all this in
debhelper, if Ubuntu uses that.