• Re: ostree (was: Filesystem snapshotting in dpkg)

    From Simon McVittie@21:1/5 to Christian Kastner on Sat Feb 15 23:20:01 2025
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)