> A package is more than a library collection. It would include test code.
> It would include meta-information. It could even include executable
> scripts that are used to actually generate the libraries on the target
> system. In general, it doesn't make sense just to grab some subtree of
> the library collection.

The distinction is further complicated by the fact that a featureful
Scheme implementation like Gambit doubles as a package manager. So a
package manager can be:

1) built into the Scheme implementation
2) external program specific to particular Scheme implementation
3) a third-party package manager supporting more than one implementation

Fortunately our main concern is interfaces, not implementations. If we
deliver a spec that works for all of these cases, it doesn't matter.

Earlier I first claimed that "package = library collection" and then
that "package = authority about where and how to find libraries". These
are conflicting definitions in both theory and practice. Sorry!

It seems that all of these concepts are useful:

1) library [i.e. some Scheme code]
2) library with metadata
3) collection of libraries [possibly all have the same metadata]
4) authoritative info on where and how to get collection of libraries

But it's not clear to me how they should be divided technically.

> There could be a simple tool converting a single library into such a
> package.

True. It could also be implicit. Not clear on this yet.

> I didn't mean that rewriting shouldn't be used but that the default
> mapping isn't that useful IMO.

I'd leave it to implementations and their user communities to figure out
a good default mapping for each; I assume there's a lot of variety in
what works well.

E.g. Kawa should probably have defaults that make sense in a JVM context.

>     - The .scm vs .import.scm vs .sls vs .sld ... file extension wars.
>
>     - The %-encoding of filenames for R6RS libraries.
>
>     - The R6RS numbers-in-library-names thing.
>
>     - Case folding in filenames.
>
>     - Reading Scheme libraries from zip/tar files.
>
>     - Reading files from URLs vs local computer.
>
>     - Reading from git and directories.
>
>
> I would call this "compiling" and not "rewriting" because it may involve
> even more.

The rewrite language could be Turing-complete and imperative, but I
would strongly prefer a non-Turing-complete and declarative one.