On Sat, 15 Feb 2025 at 21:08:03 +0100, Christian Kastner wrote:
> On 2024-12-28 15:21, Guillem Jover wrote:
> > In this case (filesystem snapshotting), I do think dpkg is (currently at
> > least) really the wrong place, for at least the following reasons:
>
> I read somewhere that Fedora can do full rollbacks because the make use
> of "ostree". See [1] for example. We have ostree in our Archive [2].
>
> I'm not familiar with it yet, but had this bookmarked as something to
> look into at some point.
ostree is not used for package management or system rollbacks in "normal",
RPM-based Fedora (the closest equivalent of a typical Debian system in the
Fedora ecosystem).
ostree is primarily designed as a way to deploy a complete /usr tree
encoded into a series of files: conceptually similar to storing the
"before" and "after" as tarballs, but more efficient. It's heavily
inspired by the way git provides content-addressed storage of source code,
but for content-addressed storage of OS binaries, and it works best when
there is a single stream of updates to a well-defined core OS or a small
number of flavours (for example "default installation of Debian 12 with
GNOME", "default installation of Debian 12 with KDE Plasma", etc. would
be fine, but arbitrary variations like "Debian 12 with GNOME except we
removed Firefox and added Chromium" don't really scale).
The most obvious way to use ostree for an OS is an appliance-like
system where installing, upgrading and removing individual packages
is not possible, and you can only upgrade or roll back the entire OS
atomically as a unit, more like an Android device than Debian. This
is far from ideal for systems that are "pets", like a typical Debian
developer's laptop/desktop system or a server that has been extensively
configured, but it's more useful for systems whose only management or
configuration is that they are deployed, upgraded, and wiped/replaced.
For example Endless OS is a Debian derivative that uses ostree this way,
Fedora Silverblue is a Fedora variant that delivers the OS and the GNOME
desktop as a monolithic ostree image rather than a series of separate RPM
packages, and it's an approach that was considered for the Arch-based
OS on the Steam Deck games console (although in fact the Deck ended
up using filesystem images like Android does, rather than ostree). The
actual software that makes up an ostree-based OS often *is* initially
delivered as packages with apt/dpkg or RPM or equivalent, but they're
centrally composed into one big filesystem tree for delivery to end users,
who never interact with individual packages.
In these OSs it isn't usually straightforward (perhaps not even possible)
to add individual packages to the OS, which results in encouraging
higher-layer mechanisms "above" the base OS, like Flatpak, Docker and
Podman/Toolbx, for user-installable packages instead.
Fedora Silverblue and other RPM-based ostree OSs use rpm-ostree,
which does allow advanced users to modify the OS locally by building a
variation of the official OS image with packages added/removed/changed,
and then doing an atomic upgrade to that modified image instead of to
the original image from the vendor. I'm not sure whether an equivalent
for apt/dpkg exists; if it does, it would most likely come from Endless.
I maintain libostree in Debian because it's also used by Flatpak as its
way to store apps and runtimes - it stores a tree of binary blobs and
doesn't need to know what those binaries actually are, so it's just as
applicable to Flatpak runtimes as it is to OSs. I could also imagine it
being useful as a more efficient alternative to a series of tarballs if
you want to store the history of some other tree of arbitrary blobs, like
a series of versions of the output of debootstrap or sbuild-createchroot,
or if you want to store several similar trees efficiently, like having a
single repository with the latest minbase and sbuild trees for bookworm,
trixie and sid.
Unfortunately I'm not able to spend time on developing a dpkg version
of rpm-ostree or other more complex infrastructure around it, but if
anyone wants to co-maintain ostree and build things like that around it,
they would be very welcome to do so.
smcv
