Thanks for your comments.

> Isn't it what Scheme registry was about? Documenting features provided
> by each Scheme *thing* available?

Correct, https://registry.scheme.org/ is about documenting features. But
packages/libraries are about downloading and running particular code.

> To me, the distinction between packages and libraries is regrettable,
> but unavoidable. A library is an abstract thing, a package is a concrete
> thing.

In common parlance, both package and library are concrete things. A
package roughly means a collection of libraries that belong together. A
library is a particular code module, and a package is a particular
collection of libraries (i.e. particular source files).

For example, "pip" is a package manager for Python packages. Each
package installs one or more .py files and may depend on other packages.
"npm" is a manager for JavaScript packages that run on Node JS, etc.

Akku and snow-chibi are Scheme package managers and work on the same
principle. There are others like guild for Guile and Raven for Chez
Scheme, that work similarly as far as I can tell.

A library according to R6RS and R7RS is a module of code that imports
other modules and exports some of its bindings. This matches the meaning
of a module or in other languages.

I agree that the distinction is regrettable, but the thing I'd prefer to
do away with is that collections are explicit instead of implicit. It's
a managerial concern about how to organize libraries into git repos or
tar files, not a RnRS-level concern. It's pretty much an arbitrary
decision which libraries to house in which Git repos, and repos do get
split and merged in practice. It would be nice if this administrative
layer could be hidden from the user who just wants to import a library.

> BLAS is a library, cblas, openblas, and ATLAS are all packages that
> implement BLAS.

AFAIK the common way to use those terms is that BLAS is a specification
or an interface, and cblas, openblas, and ATLAS are implementations of
that interface. Likewise, we don't call Scheme (or RnRS) a package but a
specification that has implementations.

> As far as I understand, languages do not have "package managers", it is
> "distributions" that have package managers. (Same abstract/concrete
> opposition.)

Both languages and distros have package managers. https://akkuscm.org/
and http://snow-fort.org/pkg are package collections for Scheme that
have associated package managers.

> Documenting all available *libraries* for Scheme seems a huge piece off
> work, although it should be possible to get an initial list of libraries
> by parsing different package repositories. But I believe that should be
> very error-prone.

> Documenting all *packages* seems a Sisyphean labour as they change all
> the time. However, it would have been nice if it was possible to agree
> upon a certain html layout, so that different scheme distributions could
> export their package list into, and packages.scheme.org could fetch
> those once a night, and format a single page.

Gathering the list is not that hard. We did that initial work with Frank
Ruben in 2019. There were not many setbacks:

https://misc.lassi.io/2019/packhack.html

https://github.com/schemedoc/packhack

A harder problem is to have a package manager that works with many
Scheme implementations. Akku accomplishes this admirably.

Having one package index that provides direct downloads of all packages
(instead of links that lead to web pages where people can manually
download packages by clicking around, as the packhack output above)
would be the crucial problem to solve. If that's solved, it doesn't
matter from Scheme.org's point of view whether people use one or many
package managers to download and install those packages. In practice,
people would probably keep using both Scheme-implementation-specific and
cross-implementation package managers. It would be nice if both kinds
work with the same package index.

To get the, two projects would have to be done:

1) Standardize the format of the package index (e.g. in a SRFI).

2) Put a comprehensive package index using that format up on scheme.org.

If a package is a collection of libraries delievered as tar file or git
repo, a Scheme program can peek inside the package and parse all the
(library ...) and (define-library ...) forms to find the libraries as
well as their imports and exports.

The automation is a matter of having a cron job run daily. The
api.scheme.org server will have the requisite infrastructure in place so
it could build the package index as well.