> 1. SRFI should not become a dumping ground of (effectively) documentation for random libraries that end up with only one implementation each, but a repository of improvements to the core Scheme language. But the current situation also makes SRFIs the easiest apparent way to get libraries into multiple implementations. That needs to change, or we’ll increasingly end up with the situation of libraries which shouldn’t really be SRFIs becoming SRFIs just to get them more widely supported.

+1 but we don't yet have an effective answer to the problem.

> 2. To that end, we need a common package manager for multiple Scheme implementations. We have a number of attempts such as Snow and Akku, but Marc Feeley’s decentralized approach seems like the best one to me so far. (A decentralized approach such as this makes supply-chain attacks Somebody Else’s Problem, for example.) I’ve had the rough details of such an approach sketched out for a while, but it would be a big effort to write the whole thing and make it actually work on multiple implementations.

I suggest the following decomposition of the problem:

- A standard for a "package.scm" metadata file. You'd put such a file in
a package's git repo, and package managers (including things like
indexers, and Gambit's built in package manager) would consult this file
to figure out how to deal with the package.

- A standard for how a package index is distributed over the internet.

- A canonical package index at packages.scheme.org.

Under no circumstances should we bless a particular piece of software as
the package manager of choice (whether for portable code or otherwise),
as this has not worked historically and is unlikely to work in the
future. We should proceed via standardization.

Does this correspond to your ideas?

IMHO we have both decentralized packages and package indexes.