[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: appimage, snap, flatpak, backport, when to use which?



On Tue, 17 Jul 2018 at 17:25:40 +0000, Marco Moller wrote:
> Is it because backports are centrally installed for all users, while
> the other options are to be duplicated for each single user?

Flatpak can work either way (per-user in ~/.local/share/flatpak or
system-wide in /var/lib/flatpak). Only an appropriately privileged user[1]
can install or remove an app or runtime system-wide; after it's been
installed, by default any user can upgrade it to its latest version[2].

I think Snap is always system-wide and AppImage is always per-user,
although I don't know for sure (I don't use those myself).

One major difference between "app"-oriented systems (Appimage, Snap,
Flatpak) and Debian backports is that if you upgrade a depended-on
package like a library from backports, everything on the system uses
that backport. For instance, if you are using a GNOME-ish desktop and
you install GLib from backports because some GNOME app in backports
depends on it, the backported GLib will also be used by components in
the base OS like gdm, GNOME Shell and NetworkManager, with a higher risk
of regressions than a pure stable system - only one copy of GLib can be
the first in the system-wide library search path. This makes maintainers
reluctant to backport lower-level libraries like GLib and GTK+, which in
turn limits the apps that can be backported - to backport Flatpak from
stretch to jessie, I had to apply some significant patches to make it
work with an old version of GLib.

In the "app"-oriented systems, dependency libraries are either bundled
with the app, or (for systems that support it, like Flatpak) taken from a
"runtime" that exists in parallel with the base OS. This means the app
is free to use a newer version of a library like GLib or GTK+, while
leaving components of the base OS using the older branch that we have
tested them against.

Some of the "app" systems (Flatpak, Snap on systems with AppArmor (only
partial coverage unless using Ubuntu's patched kernel), and Appimage when
combined with Firejail) are also designed to sandbox apps so that bugs,
security flaws or malicious code in the app can be mitigated. This is
not very effective on current Debian stable due to the need to use X11,
but should be a better security boundary in buster, where at least GNOME
(and possibly other desktops) uses Wayland by default.

    smcv

[1] Debian default: a member of the sudo group. This is configurable by
    adding polkit (policykit-1) configuration files.
[2] This is also configurable by adding polkit configuration files.


Reply to: