I really think that Gary brought up the discussion about Lisp library packaging at the right time. My logs definitely seem to hint at the existence of a formidable interest about this topic. I've taken a look at Matthew Kennedy's Lispy project, which strives to be a next generation package manager for common lisp and Gary brought up another topic, which I've thought about some years ago: an abstraction of modules above single systems (I called it "worlds").
DISCLAIMER: I've just looked very briefly at the code of Lispy!
Matthew Kennedy's Lispy aims to be simple and easy to use and is based on concepts which are proven to work for Linux distributions. Lispy is not really centrally organized, but it doesn't seem to emphasize distributed facilities very much. It seems to be quite easy though to setup a Lispy repository - all you need is some web space and a mapping file which stores metadata about all provided packages. As far as I understood it, versions are handled as chronological markers and there is a distinction between versions which come from package authors and versions which are managed by the Lispy system. There are MD5 sums of the asdf-system tarballs to enable efficient ways for verification of integrity and authentication. Matthew's design is based on his experience from managing Lisp packages for the Gentoo portage project and it actually is designed as a system to manage package distributions. In regard to my find/acquire/verify/authenticate quadruple he decided not to conflate loading of packages and installation of packages into one operation (acquire); this is maybe indeed the better thing to do. I didn't understand really who is responsible for the creation of the mapping-files; particularly where the :depends-on information is coming from. My opinion about Lispy is, that it looks very well designed. On the first sight it seems to be more suited for package maintainers than for developers. That may sound a bit weird, what I actually mean is that it seems to be more suited to manage released versions of a package. What should I do if I need a particular (perhaps locally patched) version of a package for only a particular project? If I understand Lispy right, then I would define a repository (mapping-file) for each such project. It also doesn't seem to support fetching packages out of scm repositories (cvs, darcs, svn...) and defines asdf-packages as tarballs. I still think the MD5/SHA digest should be computed from a defined order of the files of a source package and not from a tarball. Perhaps there could be an ASDF operation which computes the digest instead of compiling the files - so the digest would be defined only by the files relevant to the ASDF-System.
To me a world in the common lisp system management context is a logical bundle of systems used in a particular project or setting. It defines the context needed for development and deployment. A system-version could be uniquely identified by its system-name and a digest from the defined order of the content files. This would also mean, that world is actually defined by the a set of particular versions of asdf-packages. If one changes one of the packages it is not the same world anymore. This is similar to the concept of identity in git (see e. g. Nikodemus Siivola's explanation) Gary's command-set for working with worlds (he called them "environments") looks a bit to procedural to me. I would prefer a more declarative syntax. So instead of writing CREATE-WORLD and CLONE-WORLD as a user I would rather use a DEFINE-WORLD macro which defines the dependencies of a world. A world should know anything needed to upgrade the systems if needed. So if a system in my world is defined to track the changes of a particular branch in a scm system - so be it. I think worlds could be quite similar to the shelfs of cl-librarian. The main difference between "worlds" and "mapping repositories" (like in lispy) is that the first is a set of asdf-systems from the standpoint of a asdf-package user and the latter is from the standpoint of a package-publisher. The only reason to publish a world definition is actually to readily deployable (batteries included) projects. So the packages within a world should in some way depend on each other while the packages within a mapping repository (a "distribution") may have the only common point that they are maintained by the same person.