<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 25, 2013 at 3:49 PM, Matthew Flatt <span dir="ltr"><<a href="mailto:mflatt@cs.utah.edu" target="_blank">mflatt@cs.utah.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Caveat 1: In case you don't use the top-level default `make' target<br>
when building from the repo, this change means that you need to run<br>
`make pkg-links' when you next update.<br>
<br></blockquote><div><br></div><div style>You may also find old, wrong version .zo files hanging around confusing things after this update (I did, anyways). Probably easiest to just delete them all; since the version number changed they all have to be rebuilt regardless.</div>
<div style><br></div><div style>Robby</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Caveat 2: Feel free to skip the rest. This message is on the far end of<br>
what most of us care about in the package system. I think the changes<br>
are unavoidable, though, and I think the mostly get us to a complete<br>
and consistent design point for multi-user installations (likely<br>
common) and "/usr" versus "/usr/lib" conventions (not so much, but I<br>
think there is demand for that).<br>
<br>
<br>
When single-collection packages become the default, I don't see much<br>
use for `raco link', and instead it will be better for most of us to<br>
use `raco pkg install --link'. But I see `raco link' sticking around as<br>
an layer that some may want to use or look inside.<br>
<br>
To bring `raco link' and `raco pkg' more in line with each other, and<br>
to generally clean up a mistake (IMO) in `raco link', I've changed the<br>
behavior of `raco link -u' to be like `raco pkg ... -u': it installs a<br>
link in a user- and version-specific way, instead of in a user-specific<br>
but all-version way.<br>
<br>
Naturally, the `raco link' command now supports `-s'/`--shared', just<br>
like `raco pkg'.<br>
<br>
Links installed with `-u' now go into a "links.rktd" file that's in the<br>
version-labeled directory in the user's add-on directory, instead of in<br>
"links.rktd" (with a version regexp) outside the version-labeled<br>
directory.<br>
<br>
<br>
The "config.rktd" file in "etc" can now specify a location for the<br>
installation-wide "links.rktd" file and "pkgs" installed-package<br>
directory (with its "pkgs.rktd"). Furthermore, "config.rktd" can<br>
provide a list of additional files/directories to search. This allows<br>
the main "links.rktd" and "pkgs" to act like "/usr/lib" things, while<br>
additional directories can act like "/lib" things.<br>
<br>
The `-C'/`--links' command-line flag to `racket' has been removed.<br>
<br>
<br>
The default location for the installation-wide "links.rtkd" and<br>
"pkgs.rktd" files have moved from "etc" back into "lib". Either<br>
location seems sensible to me, but with the generalization to support a<br>
installation-wide search list, it works better to keep "pkgs.rktd"<br>
together with the installed package implementations, and it seems best<br>
to keep "pkgs" and "links.rktd" together.<br>
<br>
<br>
Note that the search path for collections goes through user-specific,<br>
version-specific links first (i.e., "user" scope), then user-specific,<br>
all-version links (i.e.,"shared" scope), and then installation-wide<br>
links (i.e., "installation" scope). The package system should similarly<br>
work sensibly if you, say, install a package at "user" scope that<br>
shadows collections for a package (possibility using the same package<br>
name) at "installation" scope. For now, you have to use `raco pkg<br>
install --force' to make that happen; longer term, I think we want an<br>
option that is like `--force' but limited to sensible shadowings.<br>
<br>
_________________________<br>
Racket Developers list:<br>
<a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a><br>
</blockquote></div><br></div></div>