[racket] raco distribute has a problem with runtime paths on win32

Now that we have packages, they provide a natural boundary. The
relative placement of files from different packages shouldn't matter,
since packages don't have a fixed installation location relative to
each other. So, I've changed `raco distribute` to preserve relative
locations only among files from the same package.

At Wed, 30 Apr 2014 12:56:01 -0600, Matthew Flatt wrote:
> At Wed, 30 Apr 2014 22:23:25 +0400, Dmitry Pavlov wrote:
> >  > Sometimes, that strategy ends up saving more information about the
> >  > source directories than you'd like to appear in an executable, such as
> >  > a user's directory name. We need some strategy to avoid that extra
> >  > information while preserving relative file locations when needed.
> > 
> > Yes, I noticed that too. There is certainly no need to save the full
> > directory structure (starting from C:\) to some "exts\\ert\\r0"
> > directory. Some deeper common ancestor should suffice (is the
> > directory structure needs to be saved at all)?
> 
> In your example, the obstacle is that `raco dist` must include both
> 
>  C:\program files\racket\share\pkgs\srfi-lite-lib\srfi\29\bundles
> 
> and
> 
>  C:\repo\era\rea\epm2004-booka\venus.rea
> 
> in the distribution, and `raco dist` currently has no way of knowing
> whether the relative path from "bundles" to "venus.rea" is significant.
> For example, "bundles" might contain some non-Racket file with the
> relative path
> 
>  ..\..\..\..\..\..\..\..\repo\era\rea\epm2004-booka\venus.rea
> 
> where that relative path is expected to work after `raco dist` copies
> everything into place for the distribution.
> 
> Of course, "bundles" doesn't contain such a relative path. Possibly,
> the fact that "bundles" is in the main installation and "venus.rea"
> isn't should be a clue for `raco dist`. Or maybe relative locations of
> runtime files should be assumed irrelevant unless a programmer
> explicitly declares otherwise.