> Honestly I'd first like to better understand the itch that packhack
> wants to scratch. [...]

> And whether it takes me 30 seconds or 3 minutes to find that first hint
> will not make a difference if afterwards I anyway need to spend 30
> minutes to 3 hours for a detailed investigation.

These are reasonable questions.

Indeed there is not much immediate benefit from a global package list,
if you have already chosen the Scheme implementation you want to use and
just want to use it to solve a particular problem.

It's more about

1) Giving a global picture of "all of Scheme" to people who are not yet
using Scheme, or people who have not yet chosen what Scheme
implementation to use for a project. It looks very good to new people if
there is a central place where information about all Scheme projects is
collected in a form that is easy to browse.

2) Encouraging portability of packages and collaboration between Scheme
implementation / package authors. I am very interested in this, as are
some other people (e.g. Göran would like Scheme libraries to be more
portable). Currently it's taken for granted that different Scheme
implementations have drastically different package collections, but some
of us would very much like to change this (by making the existing
packages portable to more implementations). This is a lot of work and
has no immediate payoff, but I believe it will be one of the most
important things to boost Scheme's future success in the 10-20 year time
frame.

3) More immediately, a global package listing can help spot gaps in
functionality that one didn't notice before. ("Hey, that other
implementation has an XYZ package and we don't. Maybe we can port it to
our implementation with a few changes.") For example in the Schemeweb
project, when people using different implementations got together for a
discussion, it became apparent that each implementation has packages the
others were not aware of. A discussion then started on how to integrate
the best stuff from the different packages into the others. I was very
happy with that, and this is exactly the kind of work that I personally
think will help Scheme win in the future.

> But maybe my workflow as described above is just wrong - and experienced
> Schemers know that e.g. relying on snowfort works.

Your workflow is probably fine, but if you're focused on immediate
goals, that benefits from a very different approach than long-term work
:) A lot of this work (schemeweb / schemedoc / etc.) has a long-term
focus so it looks kind of weird or pointless from a near-term point of view.

> At my whole workplace
> there is no other Schemer (that I'm aware of), so I just have no idea
> how other people are using Scheme.

I've also never met another Schemer at work. This seems to be the usual
case for most users. We'd like to try changing that with the long-term
work :)

> To contribute also at least a bit of concrete information: snowfort
> lists around 50 packages, theschemer more than 100. A simple mapping of
> names between these package collections will not work, but some external
> mapping is required (e.g. theschemer: tsort.scm -> snowfort: slib
> topological sort).

That's good info. I'll try to see if we can extract something useful
from theschemer. They seem like a hard-working bunch.

> I think that the
> infrastructure for these package collections is just much weaker than it
> is for the SRFIs, so more effort has to be spend to fill in the missing
> pieces.

It will indeed take some effort. I don't know if the infrastructure is
actually weaker (I've had a very good experience with both Snow-Fort and
Akku even though both are run by only one person), but the package
repositories are many and the SRFIs are all in one place, so maybe
that's why it looks better for SRFIs. Also SRFIs are better documented
since they start from the documentation and are not accepted otherwise :)