diff --git a/doc/manual/bugs.xml b/doc/manual/bugs.xml
index cb46a53b8..b479c1354 100644
--- a/doc/manual/bugs.xml
+++ b/doc/manual/bugs.xml
@@ -110,6 +110,10 @@ more-or-less cracked. We don't currently depend very much on the
collision-resistance of MD5, but we will once we start sharing build
results between users.
+It would be useful to have an option in
+nix-env --delete-generations to remove non-current
+generations older than a certain age.
+
diff --git a/doc/manual/introduction.xml b/doc/manual/introduction.xml
index 5c968edfc..e0f834385 100644
--- a/doc/manual/introduction.xml
+++ b/doc/manual/introduction.xml
@@ -41,11 +41,11 @@ during an upgrade in which part of the old version and part of the new
version are simultaneously visible (which might well cause the
component to fail).
-Likewise, it is possible to atomically roll-back after
+Likewise, it is possible to atomically roll back after
an install, upgrade, or uninstall action. That is, in a fast (O(1))
-operation the previous configuration of the system will be
-restored. This is because upgrade or uninstall actions doesn't
-actually remove components from the system.
+operation the previous configuration of the system will be restored.
+This is because upgrade or uninstall actions doesn't actually remove
+components from the system.Unused components can be
garbage-collected automatically and safely.
@@ -111,7 +111,7 @@ deployment of a complete web server with all its configuration files,
static pages, software dependencies, and so on. Nix's advantages for
software deployment also apply here, for instance, the ability
trivially to have multiple configurations at the same time, or the
-ability to do roll-backs.
+ability to do rollbacks.
diff --git a/doc/manual/package-management.xml b/doc/manual/package-management.xml
index b83cd0c4e..a6d502997 100644
--- a/doc/manual/package-management.xml
+++ b/doc/manual/package-management.xml
@@ -332,8 +332,70 @@ This will not change the
Garbage collection
+nix-env operations such as upgrades
+() and uninstall () never
+actually delete components from the system. All they do (as shown
+above) is to make a new user environment that no longer contains
+symlinks to the deleted components.
+
+Of course, since disk space is not infinite, unused components
+should be removed at some point. You can do this by running the Nix
+garbage collector. It will remove from the Nix store any component
+not used (directly or indirectly) by any generation of any
+profile.
+
+Note however that as long as old generations reference a
+component, it will not be deleted. After all, we wouldn't be able to
+do a rollback otherwise. So in order for garbage collection to be
+effective, you should also delete (some) old generations. Of course,
+this should only be done if you are certain that you will not need to
+roll back.
+
+To delete all old (non-current) generations of your current
+profile:
+
+
+$ nix-env --delete-generations old
+
+Instead of old you can also specify a list of
+generations, e.g.,
+
+
+$ nix-env --delete-generations 10 11 14
+
+
+
+After removing appropriate old generations you can run the
+garbage collector as follows:
+
+
+$ nix-collect-garbage
+
+You can alo first view what files would be deleted:
+
+
+$ nix-collect-garbage --print-dead
+
+Likewise, the option will show the paths
+that won't be deleted.
+
+Garbage collector roots
+
TODO
+The garbage collector uses as roots all store expressions
+mentioned in all files with extension .gcroot in
+the directory
+prefix/var/nix/gcroots/,
+or in any file or directory symlinked to from that directory. E.g.,
+by default,
+prefix/var/nix/gcroots/
+contains a symlink to
+prefix/var/nix/profiles/,
+so all generations of all profiles are also roots of the collector.
+
+
+