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 in large part 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 temporary state.
For example, as soon as they are installed, upgrading involves having a package manager that dynamically reassemble the system from newer parts in the Fedora package collection. One cannot file a bug against the "default offering" as a whole - a package must be chosen.
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.
In contrast for example, ChromeOS is delivered and updated as an pre-assembled atomic unit. ChromeOS is (compared to Fedora) completely inflexible, but fulfills a targeted role clearly well.
Fundamentally, packages are partial filesystem trees with
metadata - 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; possibly only for Fedora rawhide. Developers and testers can use OSTree to atomically replicate, upgrade to newer versions of, and transition between the pre-assembled trees produced by this build server.
Notably 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.
A change to include /usr/lib/passwd is required; this is implemented currently by the nss-altfiles package. See also this patch for shadow-utils.
All RPMs should stop shipping files and directories in /var. See this section of the OSTree documentation.
RPM should cope with its database living in /usr/share/rpm and being immutable.
OSTree was designed from the very beginning to work with SELinux; it just needs some bugfixes and integration on the rpm-ostree side.
Anaconda should have an OSTree backend in addition to RPM. A basic UI that provides a listview of shipped trees and allows picking them would be quite sufficient initially.
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.
If one is using OSTree in a model without a separate application mechanism (as is the case for rpm-ostree), it is potentially painful to reboot just to upgrade applications.
It would be quite easy to do a bind mount of the new /usr over
top of the old. This would avoid some of the problems dpkg/rpm
have in creating an
Starting from an