[GTALUG] Flatpak: Anyone with Experience or Opinions on It?

D. Hugh Redelmeier hugh at mimosa.com
Fri Nov 3 11:33:36 EDT 2017


| Subject: [GTALUG] Flatpak: Anyone with Experience or Opinions on It?

|  It looks like it may have been
| developed by people associated with Fedora and may be a replacement for
| RPM, APT, and the like (https://en.wikipedia.org/wiki/Flatpak).
| 
| In any case, has anyone on this list looked at this or used it? Is it
| any good? Is it a good replacement for RPM or APT? Am I off-track here
| asking that question?

I have not (knowingly) used this technology.  But Here's my take
anyway (based on guess-work!):

Packaging like dpkg and rpm is fine but the result is tied to a
release of a distro.  The main reason is that the shared libraries are
partially bound into the binary package.  But there are other subtle
and annoying difference between distros that are visible to programs.

Packaging little virtual machines is way more portable but somewhat
expensive and awkward.  This is reasonable for a service but not most
programs.

Various folks have tried to find a middle ground.  The barriers are
market buy-in, not technology.  There are two that I'm aware of:

- Canonical's "snap"

- "flatpak" sponsored by Red Hat

As usual, Canonical appears to me to be more of a control freak than
Red Hat.  Naturally, my preference is for the more open one, flatpak.

But I'm not 100% on-board.  I like old-fashioned packages (mostly).

The idea behind both, as I understand it, is to create a sandbox for
each application.  I think that each application carries around its
own libraries etc.  I hate the duplication implied.

There is also a non-technical idea.  Since flatpaks are universal
among Linux distros, the distro would no longer be in the business of
distributing the package.  And no longer standing behind it for bug
fixes and security vetting.

Win: you no longer are tied to the (possibly old) version that your
distro includes.  Example: python and perl projects seem to want to
run repos for users that are orthogonal to distros, something this
model would better support.

Win: projects no longer have to package their stuff for the various
distros.  They no longer have to match the downstream release cadence.

Lose: you have to be a connoisseur of each project from which you take
flatpaks.  Each one has a different development and QA process with
possibly unknowable risks and rewards.

Lose: when a bug is found and fixed in a shared library, each distro can
fix it with one update.  But each flatpak and snap that uses that
library needs to be re-issued and updated on each installation.

Lose: I obsessively do updates.  On each of my Fedora systems, that
amounts to "sudo dnf update".  On Windows, it is annoyingly more
intricate:
	check for updates
		note: this must be repeated until no change happens
	for x in firefox chrome Adobe Reader etc.
		perform x's check-for-updates procedure
	Microsoft Applications Store
		check for downloads
With flatpaks, Linux becomes more like Windows.

Win or lose?  python 2 must die.  But with flatpaks or snaps, each
program has its own universe so we don't need a flag day when everyone
switches.  But everyone should switch.  Yesterday.

Right now I'm fairly comfortable with Fedora and Red Hat's QA.  I
don't really want to take that on myself.  Except for a few packages
about which I have special knowledge or concerns.

As an example of the role of distros, consider the Linux Kernel.  It
used to be common for folks to take the Linus kernel and build it on
their own machine and use it in place of their distro's kernel.  It
wasn't too hard.  Linus went to some trouble to make sure a release
was clean.  I infer that things have changed.  All distros take a raw
release and fix it up before shipping it.  And you want those fixes.
It's not impossible to build a Linus kernel and use it but it is
probably not worthwhile.


More information about the talk mailing list