> For CHICKEN, we already have an s-expression based list of eggs, it's
> what our own infrastructure uses:
> http://bugs.call-cc.org/browser/project/release/4/egg-locations and
> http://bugs.call-cc.org/browser/project/release/5/egg-locations

OK, I didn't know that either. Seems you also have files like this:
<https://bitbucket.org/DerGuteMoritz/zmq/raw/master/zmq.meta> to get the
description (synopsis) for each package.

>> I don't know if there would be a reliable way to include information about
>> implemented SRFIs in there. Maybe there could be a standardized package
>> metadata file.
>
> I think that's a bit of overkill, TBH.  And different implementations
> will use different formats anyway (unless there will be a single package
> manager to rule them all).
I believe a single package _index_ containing everything would be a boon
to the growth and vitality of the community. (It would especially help
smaller implementations and lesser known/abandoned packages to be
discovered more often. It could also help with duplication of effort - I
have a couple of times missed some existing packages that could have
been used as-is, or be used as a basis for new development instead of
starting from scratch.)

A single package _manager_ may not be technically or socially possible
(due to R6RS vs R7RS differences, Unix vs Windows, "purely functional"
vs "classic" builds and other things). But if there is a single index
with listings and search across all of them, it could just show the
command lines for installing the packages from whatever package managers
they are available from. That would be almost as easy for users as
having just one Scheme package manager.

But the package index would definitely be the nicer to use the more
information it can include. Common Lisp now has <http://quickdocs.org/>
to go with their Quicklisp package manager. That site offers an awesome
interface for people to discover packages and even browse their
documentation. It's even nicer than the sites for more popular languages
like CPAN and Clojure. Something like that for Scheme would be great and
I think we should aim for that level of usability (in 5-10 years young
programmers are probably going to expect that level of usability). It
may take a few years to reach that goal but there are always little
things we can do here and there to help us along towards that goal :)