Colin Walters
7803fe1d60
There are many motivating factors. The biggest is simply that at a practical
level, the command line is not sufficient to build a real system. The docs say
that it's a demo for the library. Let's make that more obvious, so people don't
try to use `ostree admin upgrade` for their real systems, and also don't use
e.g. `ostree commit` on the command line outside of test suites/quick hacking.
This change will also help clarify the role of rpm-ostree, which we will likely
be renamed to "nts". Then use of the term "ostree" will become much clearer. And
similarly for other people writing upgraders, they can say they use libostree.
I didn't try to change all of the docs and code at once, because it's going to
lead to conflicts.
The next big steps are:
- Rename the github repo (github will inject a redirect)
- Look at supporting a build where we don't do `ostree admin`, or at least
it's only built for tests. We may want to split it off as a separate binary
or so? That way people with their own upgraders don't need to ship it.
Closes: #659
Approved by: jlebon
98 lines
3.7 KiB
Markdown
98 lines
3.7 KiB
Markdown
libOSTree
|
|
======
|
|
|
|
New! See the docs online at [Read The Docs (OSTree)](https://ostree.readthedocs.org/en/latest/ )
|
|
|
|
-----
|
|
|
|
This project is now known as "libOSTree", renamed from "OSTree"; the focus is on
|
|
the shared library. However, in most of the rest of the documentation, we will
|
|
use the term "OSTree", since it's slightly shorter, and changing all
|
|
documentation at once is impractical. We expect to transition to the new name
|
|
over time.
|
|
|
|
libOSTree is a library and suite of command line tools that combines a
|
|
"git-like" model for committing and downloading bootable filesystem trees, along
|
|
with a layer for deploying them and managing the bootloader configuration.
|
|
|
|
The core OSTree model is like git in that it checksums individual files and has
|
|
a content-addressed-object store. It's unlike git in that it "checks out" the
|
|
files via hardlinks, and they should thus be immutable. Therefore, another way
|
|
to think of OSTree is that it's just a more polished version
|
|
of
|
|
[Linux VServer hardlinks](http://linux-vserver.org/index.php?title=util-vserver:Vhashify&oldid=2285).
|
|
|
|
**Features:**
|
|
|
|
- Atomic upgrades and rollback for the system
|
|
- Replicating content incrementally over HTTP via GPG signatures and "pinned TLS" support
|
|
- Support for parallel installing more than just 2 bootable roots
|
|
- Binary history on the server side (and client)
|
|
- Introspectable shared library API for build and deployment systems
|
|
|
|
This last point is important - you should think of the OSTree command
|
|
line as effectively a "demo" for the shared library. The intent is that
|
|
package managers, system upgrade tools, container build tools and the like
|
|
use OSTree as a "deduplicating hardlink store".
|
|
|
|
Projects using OSTree
|
|
---------------------
|
|
|
|
[rpm-ostree](https://github.com/projectatomic/rpm-ostree) is a tool
|
|
that uses OSTree as a shared library, and supports committing RPMs
|
|
into an OSTree repository, and deploying them on the client. This is
|
|
appropriate for "fixed purpose" systems. There is in progress work
|
|
for more sophisticated hybrid models, deeply integrating the RPM
|
|
packaging with OSTree.
|
|
|
|
[Project Atomic](http://www.projectatomic.io/) uses rpm-ostree to
|
|
provide a minimal host for Docker formatted Linux containers.
|
|
Replicating a base immutable OS, then using Docker for applications
|
|
meshes together two different tools with different tradeoffs.
|
|
|
|
[flatpak](https://github.com/alexlarsson/xdg-app) uses OSTree
|
|
for desktop application containers.
|
|
|
|
[GNOME Continuous](https://wiki.gnome.org/Projects/GnomeContinuous) is
|
|
a custom build system designed for OSTree, using
|
|
[OpenEmbedded](http://www.openembedded.org/wiki/Main_Page) in concert
|
|
with a custom build system to do continuous delivery from hundreds of
|
|
git repositories.
|
|
|
|
Building
|
|
--------
|
|
|
|
Releases are available as GPG signed git tags, and most recent
|
|
versions support extended validation using
|
|
[git-evtag](https://github.com/cgwalters/git-evtag).
|
|
|
|
However, in order to build from a git clone, you must update the
|
|
submodules. If you're packaging OSTree and want a tarball, I
|
|
recommend using a "recursive git archive" script. There are several
|
|
available online;
|
|
[this code](https://github.com/ostreedev/ostree/blob/master/packaging/Makefile.dist-packaging#L11)
|
|
in OSTree is an example.
|
|
|
|
Once you have a git clone or recursive archive, building is the
|
|
same as almost every autotools project:
|
|
|
|
```
|
|
env NOCONFIGURE=1 ./autogen.sh
|
|
./configure --prefix=...
|
|
make
|
|
make install DESTDIR=/path/to/dest
|
|
```
|
|
|
|
More documentation
|
|
------------------
|
|
|
|
New! See the docs online at [Read The Docs (OSTree)](https://ostree.readthedocs.org/en/latest/ )
|
|
|
|
Some more information is available on the old wiki page:
|
|
<https://wiki.gnome.org/Projects/OSTree>
|
|
|
|
Contributing
|
|
------------
|
|
|
|
See [Contributing](CONTRIBUTING.md).
|