diff --git a/README b/README
index 51a6c356a7621e6259ed80c05be851a5314ff790..3c7c70805a7e80a8a87a3d5ef60cd59639372eb0 100644
--- a/README
+++ b/README
@@ -1,6 +1,6 @@
 asdf: another system definition facility                 -*- Text -*-
 
-$Id: README,v 1.4 2001/08/03 01:13:30 dan_b Exp $
+$Id: README,v 1.5 2001/08/06 01:10:05 dan_b Exp $
 
 This system definition utility talks in terms of 'components' and
 'operations'.
@@ -93,17 +93,51 @@ happen one way or another.
 This is a string.  It must satisfy the restrictions imposed on a
 portable pathname character.
 
+[ This restriction is probably going away ]
+
 *** a version identifier (optional, will default to parent's version)
 
-This is used by the check-component-version operation (see later).
+This is used by the test-system-version operation (see later).
 
 *** dependencies on its siblings  (optional but often necessary)
 
-This slot contains a list whose elements are each names of siblings,
-or lists of (name version) for siblings
+There is an excitingly complicated relationship between the initarg
+and the method that you use to ask about dependencies
+
+Dependencies are between (operation component) pairs.  In your
+initargs, you can say
+
+:in-order-to ((compile-system (load-system "a" "b") (compile-system "c"))
+	      (load-system (load-system "foo")))
+
+- before performing the compile-system operation on this component, we
+must perform the load-system operation on each of "a" and "b", and
+before performing load-system, we have to load "foo"
+
+This is pretty similar to what ACL defsystem does.  mk-defsystem is
+less general: it has an implied dependency 
+
+  for all x, (load x) depends on (compile x)
+
+and using a :depends-on argument to say that b depends on a _actually_
+means that
+
+  (compile b) depends on (load a)
+
+In asdf, the dependency information for a given component and
+operation can be queried using (depends-on operation component), which
+returns a list
+
+((load-system "a") (load-system "b") (compile-system "c") ...)
 
-[ this will change.  Dependencies are between (component operation)
-pairs, not between components themselves ]
+depends-on can be subclassed for more specific component/operation
+types: these need to (call-next-method) and append the answer to their
+dependency, unless they have a good reason for completely overriding
+the default dependencies
+
+(If it weren't for CLISP, we'd be using a LIST method combination to
+do this transparently.  But, we need to support CLISP.  If you have
+the time for some CLISP hacking, I'm sure they'd welcome your fixes)
 
 *** a filesystem location
 
@@ -303,7 +337,6 @@ the package that they evaluate defsystem forms in
 
 <Krystof> You don't want to have (defsystem partition ...) being read in the
 +cl-user package
-<rahul> hrm
 <Krystof> Because that will intern a cl-user:partition symbol
 <rahul> yeah, accidental interning could be a problem
 <Krystof> Which will then collide with the partition:partition symbol
@@ -318,28 +351,8 @@ with symbols and depend on :case :common to map them into customary case.
 *** shortcut to setting up dependencies using :serial, :parallel
   options.
 *** split into native syntax and mixin for mk- syntax extras
-
-** Argh dependencies.
-
-Our dependencies are conceptually wrong.  Dependencies exist between
-the application of operations to components, not the components
-themselves.  For example, there is an implied dependency in
-mk-defsystem
-
-  for all x, (load x) depends on (compile x)
-
-and specifying that b depends on a _actually_ means that
-
-  (compile b) depends on (load a)
-
-We currently intend to do something rather like ACL's defsystem :
-
-:in-order-to (compile-system (load-system "a" "b")
-              load-system (load-system "foo"))
-
-We can combine this with a gf that has methods specialised on
-component and operation to augment the dependency list with "standard"
-dependencies: e.g. in-order-to (load-system x), first (compile-system x)
+*** reintroduce :depends-on or some other succint form of dependency 
+  specification
 
 ** the :pathname argument is misnamed
 
@@ -352,6 +365,9 @@ like a pathname, we shouldn't fool the user into thinking it is one
 ** all of the above
 ** reuse the same scratch package whenever a system is reloaded from disk
 ** defsystem syntax for EQL methods
-** dependency circularities: test it works
 ** versions
+** traverse
 
+this operation instantiation thing sucks somewhat, as we don't
+transfer arguments in any meaningful way.  if compile calls load calls
+compile, how do we access the original proclamations?