92 lines
3.8 KiB
Markdown
92 lines
3.8 KiB
Markdown
|
# What is rpm-ostree?
|
||
|
|
|
||
|
|
rpm-ostree is a hybrid image/package system. It uses
|
||
|
|
[OSTree](https://ostree.readthedocs.io/en/latest/) as a base image
|
||
|
|
format, and accepts RPM on both the client and server side, sharing
|
||
|
|
code with the [dnf](https://en.wikipedia.org/wiki/DNF_(software)) project;
|
||
|
|
specifically [libhif](https://github.com/rpm-software-management/libhif).
|
||
|
|
|
||
|
|
# Getting started
|
||
|
|
|
||
|
|
If you want to try the system as a user, we recommend
|
||
|
|
[Project Atomic](http://www.projectatomic.io/). If you are
|
||
|
|
interested in assembling your own systems, see
|
||
|
|
[compose server](manual/compose-server.md).
|
||
|
|
|
||
|
|
# Why would I want to use it?
|
||
|
|
|
||
|
|
One major feature rpm-ostree has over traditional package management
|
||
|
|
is atomic upgrade/rollback. It supports a model where an OS vendor
|
||
|
|
(such as [CentOS](https://www.centos.org/) or
|
||
|
|
[Fedora](https://getfedora.org/) can provide pre-assembled "base OS
|
||
|
|
images", and client systems can replicate those, and possibly layer on
|
||
|
|
additional packages.
|
||
|
|
|
||
|
|
rpm-ostree is a core part of the [Project Atomic](http://www.projectatomic.io/)
|
||
|
|
effort, which uses rpm-ostree to provide a minimal host for
|
||
|
|
Docker formatted Linux containers.
|
||
|
|
|
||
|
|
We expect most users will be interested in rpm-ostree on the client
|
||
|
|
side, using it to replicate a base system, and possibly layer on
|
||
|
|
additional packages, and use containers for applications.
|
||
|
|
|
||
|
|
# Why not implement these changes in an existing package manager?
|
||
|
|
|
||
|
|
The [OSTree related projects](https://ostree.readthedocs.io/en/latest/manual/related-projects/)
|
||
|
|
section covers this to a degree. As soon as one starts taking
|
||
|
|
"snapshots" or keeping track of multiple roots, it uncovers many
|
||
|
|
issues. For example, which content specifically is rolled forward or
|
||
|
|
backwards? If the package manager isn't deeply aware of a snapshot
|
||
|
|
tool, it's easy to lose coherency.
|
||
|
|
|
||
|
|
### Filesystem layout
|
||
|
|
|
||
|
|
A concrete example is that rpm-ostree moves the RPM database
|
||
|
|
to `/usr/share/rpm`, since we want one per root `/usr`. In contrast,
|
||
|
|
the [snapper](http://snapper.io/) tool goes to some effort to
|
||
|
|
include `/var/lib/rpm` in snapshots, but
|
||
|
|
avoid rolling forward/back log files in `/var/log`.
|
||
|
|
|
||
|
|
OSTree requires clear rules around the semantics
|
||
|
|
of directories like `/usr` and `/var` across upgrades, and
|
||
|
|
while this requires changing some software, we believe the
|
||
|
|
result is significantly more reliable than having two separate
|
||
|
|
systems like yum and snapper glued together, or apt-get and BTRFS,
|
||
|
|
etc.
|
||
|
|
|
||
|
|
### User experience
|
||
|
|
|
||
|
|
Furthermore, beyond just the mechanics of things like the filesystem
|
||
|
|
layout, the implemented upgrade model affects the entire user
|
||
|
|
experience.
|
||
|
|
|
||
|
|
For example, the base system OSTree commits that one replicates from a
|
||
|
|
remote server can be assigned version numbers. They are
|
||
|
|
released as coherent wholes, tested together. If one is simply
|
||
|
|
performing snapshots on the client side, every client machine
|
||
|
|
can have different versions of components.
|
||
|
|
|
||
|
|
Related to this is that rpm-ostree clearly distinguishes which
|
||
|
|
packages you have layered, and it's easy to remove them, going back to
|
||
|
|
a pristine, known state. Many package managers just implement a "bag
|
||
|
|
of packages" model with no clear bases or layering. As the OS evolves
|
||
|
|
over time, "package drift" occurs where you might have old, unused
|
||
|
|
packages lying around.
|
||
|
|
|
||
|
|
# But still evolutionary
|
||
|
|
|
||
|
|
On the other hand, rpm-ostree in other ways is very evolutionary.
|
||
|
|
There have been many, many different package managers invented -
|
||
|
|
why not adopt or build on one of those?
|
||
|
|
|
||
|
|
The answer here is that it takes a long time for tooling to be built
|
||
|
|
on top of a package format - things like mirroring servers. Another
|
||
|
|
example is source format representations - there are many, many
|
||
|
|
tools that know how to build source RPMs.
|
||
|
|
|
||
|
|
From the perspective of distribution which has all of that ecosystem
|
||
|
|
built up, rpm-ostree does introduce a new binary format (ostree), but
|
||
|
|
otherwise includes an RPM database, and also operates on packages. It
|
||
|
|
is not a new source format either.
|
||
|
|
|