packaging
/
ostree
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

doc: Split overview into chapters, expand a bit

This commit is contained in:
Colin Walters 2013-08-22 09:17:08 -04:00
parent d58d6a6ef2
commit 032f1316ad
1 changed files with 109 additions and 104 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

49
doc/overview.xml
View File

@ -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
HTTP. It is designed for the model where a build server
assembles one or more trees, and these are replicated to
clients, which can choose between fully assembled (and
hopefully tested) trees.
The OSTree core emphasizes replicating read-only OS trees via
HTTP, and where the OS includes (if desired) an entirely
separate mechanism to install applications, stored in <filename
class='directory'>/var</filename> if they're system global, or
<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
than mutating the currently running filesystem, the package
manager could assemble a new filesystem tree that includes the
new package, record it 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.
package system, where the contents of <filename
class='directory'>/usr</filename> are computed on the client.
For example, when installing a package, rather than mutating the
currently running filesystem, the package manager could assemble
a new filesystem tree that includes the new package, record it
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
possible to replicate a given filesystem tree from an OSTree
repository into both a BTRFS disk and an XFS-on-LVM
deployment. Note: OSTree will transparently take advantage of
some BTRFS features if deployed on it.
on top of any filesystem or block storage layout; it's possible
to replicate a given filesystem tree from an OSTree repository
into plain ext4, BTRFS, XFS, or in general any Unix-compatible
filesystem that supports hard links. Note: OSTree will
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>