Matthew Flatt <mfl...@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 _________________________ Racket Developers list: http://lists.racket-lang.org/dev
