Package systems versus image systems

Broadly speaking, software update systems for operating systems tend to fall cleanly into one of two camps: package-based or image-based.

Package system benefits and drawbacks

Image benefits and drawbacks

How RPM-OSTree provides a middle ground

rpm-ostree in its default mode feels more like image replication, but the underlying architecture allows a lot of package-like flexibility.

In this default mode, packages are composed on a server, and clients can replicate that state reliably. For example, if one adds a package on the compose server, clients get it. If one removes a package, it's also removed when clients upgrade.

One simple mental model for rpm-ostree is: imagine taking a set of packages on the server side, install them to a chroot, then doing git commit on the result. And imagine clients just git pull -r from that. What OSTree adds to this picture is support for file uid/gid, extended attributes, handling of bootloader configuration, and merges of /etc.

To emphasize, replication is at a filesystem level - that means things like SELinux labels and uid/gid mappings are assigned on the server side.

On the other hand, rpm-ostree works on top of any Unix filesystem. It will not interfere with any filesystem or block-level snapshots or backups such as LVM or BTRFS.

Who should use this?

Currently, rpm-ostree operates on a read-only mode on installed systems; it is not possible to add or remove anything on the client system's /usr. If this matches your deployment scenario, rpm-ostree is a good choice. Classic examples of this are fixed purpose server farms, "corporate standard build" laptop/desktops, and embedded devices.

Of course, one can pair it with a dynamic application mechanism such as Docker, and have a reliable base, with a flexible application tool. This is the rationale behind Project Atomic.

Container technology is flexible enough for "privileged" containers to affect the host. For example, using the atomic command, one can atomic run centos/tools and have a flexible shell with access to /host.

Is it worth supporting composes both on client and server?

In short, our belief is yes. Long term, rpm-ostree offers a potential unified tooling via package layering.