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 world.
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
software packages.
... 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?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader

On Wed, Oct 19, 2016 at 04:54:45PM +0200, Alexander Larsson wrote:
> I actually had had a copr setup with a custom redhat-rpm-config that
> automatically built things in a different prefix. Most things built
> just fine with zero specfile changes.
Well, that's encouraging, at least. It still means some degree of doing
everything twice, but at least it's mostly computers doing it. :)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader

Hi,
during last FPC meeting we agreed[0] that we need some standardization
of macro related to builds where builddir != srcdir (and with
possibility to make it builddir = srcdir).
I was working to make guidelines for ninja and meson. For ninja it
doesn't matter from where you build (it's like make), but meson itself
accepts ONLY out-of-tree builds. Would be nice to get system-wide
(rpm-wide?) macro which stands for:
1) source directory where CMakeLists.txt/meson.build/configure are
2) build directory (I think _target_platform is a good candidate)
to make out-of-tree conversion to in-tree, you do the RPM variable override.
For example, in openSUSE it's defined in cmake[1] as __builddir and __srcdir.
Ideas, suggestions are appreciated!
[0] https://meetbot.fedoraproject.org/fedora-meeting-1/2016-10-13/fpc.2016-10...
[1] https://build.opensuse.org/package/view_file/openSUSE:Factory/cmake
/cmake.macros?expand=1
--
-Igor Gnatenko