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.
OSTree, when replicating content from a build server, effectively reverts the Dracut host-only mode. Furthermore, at the moment we hardcode /etc/machine-id, which is a definite bug that needs to be fixed. Possibly systemd should support reading the machine ID from the kernel commandline, as it's the only host-writable area available in early boot.
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.
There are two primary issues. First, OSTree mandates that the running tree be immutable, and requires construction of a new tree. This is just a deep mismatch with how package managers are built. Second, current package managers are totally unaware of the existence of the OSTree repository at /ostree/repo which holds binaries. A naive implementation would just redownload the packages, which would be quite slow.
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
OSTree allows not just dual booting - one can just as easily have 50 or more trees locally. Suppose that you're tracking Fedora rawhide, and an upgrade breaks Mesa+GNOME (or sound, or something else). You can not only easily revert to a last known good tree, you can use OSTree to download intermediate builds from the build server and bisect across them. Given the ability to do local builds from git, automating bisection across source code is entirely possible as well.
OSTree mandates that operating system updates work entirely offline. Work that has been prototyped already in the gnome-continuous codebase then takes updated content from an OSTree repository, and incrementally updates a cached VM disk image from the host side. This could allow booting updated systemd RPMs within minutes after Koji builds. This is fundamentally different from RPM %check as we are booting the tree as it will be shipped to the user - whereas RPM checks may run in e.g. a RHEL6 kernel.
Many contributors to Fedora are also Red Hat engineers working on Red Hat Enterprise Linux. An example way to use OSTree is to have EL7 installed in the physical /, and install Fedora in /ostree/deploy/fedora. One can choose whether or not to share /home.
This is an obvious use case - you can run a stable release, and periodically try the development release on bare metal with a great deal of safety, particularly if you choose not to share /home. In this model, the only major risk is the newer kernel containing filesystem corrupting bugs.
You can keep your OS installed in /, manage it with a traditional package manager, but have a small (e.g. base/minimal) tree installed via OSTree to use as a "recovery partition" when something goes wrong. Except unlike traditional recovery partitions, you can easily delete it if you want space, upgrade it offline, etc.
OSTree allows taking a "cloud" like approach to a cluster of traditional servers. Every upgrade is atomic and (relatively) efficient, and can be served by any plain HTTP server.