Build:
- defsystem
- asdf (with some additions and extensions many of which are not
mature)

Install
- asdf-install
- clbuild
- common-lisp-controller
- cl-librarian

There are also related topics as:
- autoloading (seen smth in cllib)
- package system convinience libraries such as conduit packages or
hierarchical packages
- unit testing suites

Is there some overview of the question for newbies on the net?

And for inspiration, you may have a look at the various linux
distributions each with their own package management system (rpm,
emerge, apt-get, etc).

| I want to study portable cl build/install related programs/utilities
| thoroughly. For now I am aware of the following ones:

Apart from those two mentioned, from the top of my head (without
consulting google):

- Joachim H. Laubsch's defsystem is in the cmu-ai repo from around 92.
- Peter Bengtson wrote YADS (Yet another defsystem facility) around 97.
- Ora Lassila wrote a defsystem included with wilbur-rdf.

Lots of packages also come with system definition and configuration
facilities, like powerloom, ytools with lsy etc.

Commercial lisp implementations (lispm, franz lw) each come with their
own defsystems.

Once you read KMP's paper you can write your own defsystem in an
afternoon or weekend.

[It may be easier to count grains of sand in the beach than the number
 of system definition facilities out there.  Or something.  Did you have
 a specific reason for this study?]

ftp://publications.ai.mit.edu/ai-publications/pdf/AITR-874.pdf

Satisfactory defsystem should cover the following questions:
- automated installation from manageable list of locations (like /etc/
apt/sources.list)
- check of installation correctness
- support of the "worlds" (like version series in debian: etch/
lenny/... and apt-get dist-upgrade)
- introspection (like dpkg -S) to find:
-- where the system is located
-- what is its version
-- what are the dependencies
-- to what system given file/package/symbol belongs
-- find system by keywords in its description
- ability to add new library with a well described standard procedure
(and people who support it)
- ability to convert from heritage defsystems or integrate them
smoothly

How many time it would take in production to learn new defsystem every
time I need new library? E.g. debian has (mainly) two ways of
installing:
1. use apt (easy)
2. download binaries/build from sources (more powerful)
I think that's enough.

If there are many defsystems, I'd like to see some methodics to
coercing them to some common solution. E.g. "my-super-defsystem-to-
asdf".

* Operations on components don't happen in the context of a call to
the parent system.
* Pervasive use of soft links makes Windows users second class
citizens.
* Inability to have multiple versions of the same system defined.

  First consideration is rather serious. But parent system is
accessible through asdf metadata, so we can know something about
context of operation anyway. It is necessary to know what exactly did
Mudballs authors wanted from the context.
  Second is a small issue which can be solved easily due to
extensibility of asdf architecture. I solved it (for lispworks) in a
several hours (if I was less stupid and more lucky, I could made it in
a hour, but I spent many time writing a clone of already existing
readlink.exe program). http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/2f...
  I still didn't try to address third issue, but we have
asdf::*central-registry* and asdf::*system-definition-search-
functions*. Certanly, this is more than enough to make multi-version
world possible. Just the most stupid thing:
write in initialization file:
(require :asdf)
(push #+lib1.1 (list "/usr/local/lib/lisp/1.1/") #+lib1.2 (list "/usr/
local/lib/lisp/1.2/")
  asdf::*central-registry*)
This switches the whole universe. There is also already an extension
which allows to switch universes.
To work per-library, one can have an alist of versions and write one's
own search function which
reads that alist and finds an appropriate version by its folder name,
e.g.
(push '(:foo . 1.4) *asfd-version-alist*)
and function would find cl-foo-1.4, but not cl-foo-1.5
  So, most of the problems in the rationale of Mudballs are solved
easily. Instead of solving them by adding compatible extensions to
asdf, Mudballs author (I could not find his name on the site)
preferred to create new tool with incompatible syntax and provided
even no tool for automatic conversion of asdf systems. If he would
promote Mudballs rather actively, this will, on my opinion, lead to
further fragmenting of lisp society which is not that strong.
  I didn't thought about installation yet, but clbuild looks like
almost ok. Its problem is that it is developed for unstable
development and does not address notion of stable
"distributions" (like apt does). However, it can be solved easily too.
If someone wants to provide a "distribution", he can just publish it
as repo. Users will need only take projects and dependencies files and
then do sh clbuild update ... (their projects) The second clbuild's
problem (for me) is that tarball distributed libraries are not
included. There is rationale for that, and it is respectable.
Meanwhile, the problem of getting list of library locations persist so
we have some gap in functionality required.

Then, asdf syntax is acceptable, it is rather flexible, and asdf
itself is extensible in several directions. E.g. if we don't like asdf
compilation vs loading behavior, and we don't like :serial t, we can
define our own 'asdf::smart-load-op which acts as we want. Syntax can
also be extended using #+feature mechanism. E.g.
(defsystem :foo-library
  #+asdf+ (:package "FOO" "packages.lisp")
  (:depends-on ...))
If some user do not have an extended asdf, he would still be able to
load.
So my current intension is in fact to improve asdf by unleashing its
hidden (not hidden, in fact, but very transparent and even documented)
potential.