doc: Split overview into chapters, expand a bit

doc/overview.xml

@@ -1,6 +1,6 @@
 <?xml version="1.0"?>
 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
-               "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [
+"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [
 <!ENTITY version SYSTEM "../version.xml">
 ]>
 <part id="overview">
@@ -23,7 +23,9 @@
       blend of the advantages (and disadvantages) of both.
     </para>
 
-    <simplesect id="ostree-package-comparison">
+  </chapter>
+  
+  <chapter id="ostree-package-comparison">
     <title>Comparison with "package managers"</title>
     <para>
       Because OSTree is designed for deploying core operating
@@ -41,24 +43,27 @@
       descriptions of individual components.
     </para>
     <para>
-	The OSTree core emphasizes replicating read-only trees via
+      The OSTree core emphasizes replicating read-only OS trees via
-	HTTP.  It is designed for the model where a build server
+      HTTP, and where the OS includes (if desired) an entirely
-	assembles one or more trees, and these are replicated to
+      separate mechanism to install applications, stored in <filename
-	clients, which can choose between fully assembled (and
+      class='directory'>/var</filename> if they're system global, or
-	hopefully tested) trees.
+      <filename class='directory'>/home</filename> for per-user
+      application installation.
     </para>
     <para>
       However, it is entirely possible to use OSTree underneath a
-	package system; For example, when installing a package, rather
+      package system, where the contents of <filename
-	than mutating the currently running filesystem, the package
+      class='directory'>/usr</filename> are computed on the client.
-	manager could assemble a new filesystem tree that includes the
+      For example, when installing a package, rather than mutating the
-	new package, record it in the local OSTree repository, and
+      currently running filesystem, the package manager could assemble
-	then set it up for the next boot.  To support this model,
+      a new filesystem tree that includes the new package, record it
-	OSTree provides an (introspectable) C shared library.
+      in the local OSTree repository, and then set it up for the next
+      boot.  To support this model, OSTree provides an
+      (introspectable) C shared library.
     </para>
-    </simplesect>
+  </chapter>
 
-    <simplesect id="ostree-block-comparison">
+  <chapter id="ostree-block-comparison">
     <title>Comparison with block/image replication</title>
     <para>
       OSTree shares some similarity with "dumb" replication and
@@ -76,15 +81,16 @@
     </para>
     <para>
       Because OSTree operates at the Unix filesystem layer, it works
-	on top of any filesystem or block storage layout; it's
+      on top of any filesystem or block storage layout; it's possible
-	possible to replicate a given filesystem tree from an OSTree
+      to replicate a given filesystem tree from an OSTree repository
-	repository into both a BTRFS disk and an XFS-on-LVM
+      into plain ext4, BTRFS, XFS, or in general any Unix-compatible
-	deployment.  Note: OSTree will transparently take advantage of
+      filesystem that supports hard links.  Note: OSTree will
-	some BTRFS features if deployed on it.
+      transparently take advantage of some BTRFS features if deployed
+      on it.
     </para>
-    </simplesect>
+  </chapter>
 
-    <simplesect id="ostree-atomic-parallel-installation">
+  <chapter id="ostree-atomic-parallel-installation">
     <title>Atomic transitions between parallel-installable read-only filesystem trees</title>
     <para>
       Another deeply fundamental difference between both package
@@ -126,6 +132,5 @@
       perform a basic 3-way diff, and apply any local changes to the
       new copy, while leaving the old untouched.
     </para>
-    </simplesect>
   </chapter>
 </part>