[racket-dev] A grab-bag of issues

At Thu, 4 Jul 2013 12:52:10 -0400, Sam Tobin-Hochstadt wrote:
> All of these are about packages/the new repository organization.
> 
> 0. I think we should have a new `#lang info` for info.rkt files --
> `setup/infotab` seems pretty arbitrary.   I'll do this if no one
> objects.

That sounds fine to me.

> 1. Builds treat too much as core. Specifically, `raco setup`
> pre-builds some things single threaded, but too many:

Yes. This is probably not too difficult to fix, but I haven't gotten to
it.

> 2. It's possible to get lots of undefined tags in the documentation
> builds.  Should this be remedied with more build dependencies, or will
> it be fixed with the online documentation server, or something else?

Mostly through an online documentation server and declaring certain
documentation links to be "indirect" (which may sometimes involve
adjusting the documentation content).

> 3. Rerunning `make` at the top-level loses the old set of PKGS
> specified.  Should there be a `configure` setting for this to make it
> permanent?

I agree that something should be done, but I'm not sure of the right
way to do it offhand. as you might imagine, it can be a little tricky
to find something that works with both Unix/Mac and Windows.

> 4. The top-level build has no "cgc" targets.

Do we want them? I'm more inclined to gradually deprecate CGC.

> 5. GitHub recently introduced "Releases", which allow you to serve
> arbitrary downloads. This might be useful for the "plt/libs"
> repository.  More info here:
> https://github.com/blog/1547-release-your-software . Even without
> this, we might want to switch to downloading native packages as zip
> files instead of requiring git to build from source.

I imagined that we would having a catalog server for the native-library
packages, but it's good to know about support for Releases from GitHub,
and I'll look into that more.

> 6. Should the launchers for things like 'setup-plt' and 'mzc' move to
> `compatibility-lib`?

Yes --- or maybe even a "mzc" package, since "compatibility-lib" gets
pulled in by packages that probably shouldn't imply a `mzc' executable.

> 7. I think 'raco setup' should exit with a non-0 exit code when there
> are dependency problems.

That sounds right.