[racket-dev] advice on the 6.x build system.

Matthew Flatt <mflatt at cs.utah.edu> writes:

>
> That said, is there a particular reason that basing the build on the
> git repo would be better?
>

One reason is that I need I need to track from release to release the
files that are removed from the racket source by debian for
licensing-related reasons. Currently this looks like:

╰─ (git)-[new-master]-% git diff --stat dfsg..upstream
 .../drdr/static/jquery-1.6.2.min.js    |   18 +
 .../resources/js/libs/gumby.min.js     |    1 +
 .../js/libs/jquery-1.9.1.min.js        |    5 +
 .../libs/jquery.mobile.custom.min.js   |    3 +
 .../js/libs/modernizr-2.6.2.min.js     |    4 +
 .../resources/js/plugins.js            |    8 +
 .../racket/benchmarks/common/maze.sch  |  680 ++
 .../racket/benchmarks/common/maze2.sch |  695 ++
 .../common/psyntax-input.txt           | 4296 ++++++++++++
 .../benchmarks/common/typed/maze2.rktl |  772 ++
 .../racket-test/tests/xml/xmltest.zip  |  Bin 0 -> 107060 bytes

I used to do this by importing the tarballs on top of the git history,
but since 6.0 this import creates a massive diff because of all the
re-arranging that happens in tarball creating process. At this point the
I the history becomes difficult to follow (or at least ugly).  From our
point of view, once we have to delete things, the tarballs also lose
their status as an "pristine work of upstream".

A second reason is that I want to be able to able to backport patches to
older releases of racket running on Debian.  This is much easier if I
can just use "git cherry-pick".

A third reason (related) is that from time to time I need to test the
Debian packaging of an as yet unreleased racket version, e.g. to check
if a build failure is fixed in the upcoming 6.1.1 branch.

d