An instance of rpm-ostree for Fedora. This project takes multiple RPM package sets from Fedora, assembles them on the build server side, and stores these trees in an OSTree repository. Client systems can them atomically upgrade and switch between these trees.
See installation.
Fedora today is an extremely flexible system. One can find Fedora builds running on everything from hobbyist ARM devices, to workstations, to testing servers.
This flexibility derives primarily from the fact that from a technological point of view, Fedora is a collection of packages. While pre-assembled "deliverables" such as the Live CDs are distributed by the project, they are only a transitory state. As soon as they are installed, upgrading involves having a package manager the dynamically reassemble the system from newer parts in the Fedora package collection.
Furthermore, nearly every aspect of the Fedora infrastructure (and documentation) is structured in terms of packages, from user-facing tools such as Bugzilla and Bodhi, to developer tools such as Koji. The announced security updates are based on package names.
One cannot file a bug against the "default offering" as a whole - a package must be chosen.
In contrast for example, ChromeOS is delivered and updated as an atomic unit. It's far less flexible, but fulfills a targeted role clearly well.
Fundamentally, package systems are partial filesystem trees -
they are assembled by a package manager into a complete bootable
tree. It's important to emphasize that it is only
these
OSTree allows an OS distributor to
ship
This allows a middle ground between the two extremes of a combinatorial explosion of packages, and a singular OS.
For example, these are some of the trees the current prototype generates:
The first goal of this project is to be an additional deployment option built in the Fedora infrastructure. In this phase, developers and testers can use OSTree to replicate and atomically transition between the pre-assembled trees produced by this build server.
In this phase, no common mechanism for additional software installation is provided. That said, individual trees can do so; for example server/docker-io tree can use Docker to install and run server container applications independent of OSTree.
This phase does include basic integration testing on the build server side, which will be a major benefit to the Fedora project and its downstreams.
This phase would be allowing "layering" of trees. For example, if one installs the base/minimal tree, one could imagine taking the strace package, and computing a new filesystem tree which is the union of the two.
While plain standalone ELF executables would work with no modification, a generalization of this kind of dynamic layering implies a higher level above OSTree that is aware of things like ldconfig and gtk-update-icon-cache and how to trigger them when layers are combined.
Conceptually, this is a step back towards combinatorics. For example, if libvirt is a layer that could be applied on top of the base server layer as well as the workstation layer, then there would need to be some notion of dependencies.
There is absolutely no reason one could not just use the package manager on the client side to download and assemble packages - but rather than operating live on your current root, OSTree allows setting up the chosen tree for the next boot atomically.
The problem is making this sort of thing efficient and scalable; it would require careful integration of the local OSTree repository and the package manager caching to operate at a speed comparable to traditional package management.