On Wednesday, October 19, 2016 7:50:23 AM EDT Matthew Miller wrote:
In the medium-term future, we might want to provide some application
software to users as Flatpak bundles in addition to traditional RPM
form. This should be generally transparent to users but provide (at
least) two advantages. First, these applications can be sandboxed, and
only able to access resources they're specifically allowed to,
increasing security. And second, users may have easier options for
mixing and matching application versions that match their personal
needs. And as a project, as Flatpak gains traction as a cross-platform
solution, providing a whole bunch of Fedora packages in this way even
to users of other distros helps increase our impact and usefulness to
The Flatpak design splits the runtime from the application in the
filesystem — apps are built expecting the runtime at /usr as normal,
but are installed into a tree at /app. I'm not proposing that we move
to having /app, but the idea of having a separate tree is pretty
fundamental. As it stands right now, if we want to build existing RPMs
as Flatpaks, we have to either do some very sketchy magic with
relocation, or else hack on the specfiles.
So, the crazy idea: what if, for applications which would be useful as
a Flatpak, we allow /opt/fedora/apps/[appname-version] as an allowed
prefix? Then, the exact same RPMs could be used by someone who doesn't
care about Flatpaks _and_ to construct the Flatpak, with no
really-invasive changes. (Perhaps by making a link inside the Flatpak,
or simply by asking for an extension to Flatpak to support the
different application root.)
From the FHS 3.0:
/opt is reserved for the installation of add-on application
... but it doesn't actually define what "add-on application software
packages" are. Although we integrate it all together in Fedora,
arguably a lot of our software could qualify.
From our current Packaging Guidelines:
/opt and its related directories (/etc/opt and /var/opt) is
reserved for the use of vendors in the FHS. We have reserved the
fedora name with LANANA for our use. If a package installs files
into /opt it may only use directories in the /opt/fedora hierarchy.
Fedora attempts to organize this directory by allocating a
subdirectory of our /opt/fedora directory for specific subsystems.
If you think you need to use /opt/fedora please file an FPC ticket
to decide whether it's a valid use of /opt and what subdirectory
should be allocated for your use.
.... so, it's not completely outside the realm of precedent. I know
it's very different from our existing "blend everything into /usr"
approach, but I think it might be worth doing for the increased
flexibility. What do you all think?
One of the major issues I see with this approach is the use of outdated
libraries and other outdated packages. I know that Flatpak is important to a
large number of people, but that isn't enough to suggest creating a prefix for
each individual application, unless applications packaged in this way were
separate from other packages, at which point we'd essentially have a distro on
The solution to the above, as people who are for Flatpak would say, is to just
keep the packages that make up your Flatpak as up to date as possible. If that
were the case, we would have duplicate packages in each prefix increasing the
size of a Fedora installation on all systems not using btrfs or a similar
filesystem with deduplication or a similar technology.
The solution to packaging RPMs as Flatpaks should be obvious. Simply changing
the prefix to a temporary directory and using the resulting file tree would be
the way to go.
John M. Harris, Jr. <johnmh(a)openblox.org>
Project Lead, OpenBlox