On Mon, Oct 1, 2018 at 12:16 PM Owen Taylor <otaylor(a)redhat.com> wrote:
As some of you are aware, I've been working on a project to make it possible to build
Flatpaks out of Fedora RPMs within the Fedora infrastructure. One of the key elements of
this is rebuilding RPMs with prefix=/app. The way that Flatpak works is that at runtime,
two filesystems are mounted:
/usr- the "runtime" - standard Fedora libraries shared by multiple Flatpaks
/app - the application and libraries distributed inside the app container
To rebuild a package with prefix=/app, it is rebuilt in a module that has the
'flatpak-rpm-macros' package installed in the buildroot (this is automatically
done when your package depends on the flatpak-runtime module.) The flatpak-rpm-macros
package overrides %{_prefix}, %{_datadir}, etc, and points them to /app.
About 90% of packages just work without any changes at all, but other packages need some
(mostly minor) changes.
Generally, I'd consider most changes that are needed things that make the packages
more compliant with the packaging guidelines - we expect packages to honor %{_prefix}. But
there is one assumption some of the changes make that Petr Pisar pointed out to me that
everybody might not agree with:
%{_prefix} and related macros specify the install location of this package, they
should not be used for paths to tools used as BuildRequires.
So I wanted to run that idea past the packaging list for comment. In many cases, that
assumption can be fixed inside installed RPM macros (meson, ninja, and qt5 macros have
already been fixed.) But in a few cases a spec file does make that assumption.
This is actually a problem for when things like systemd binaries are
being referenced (as many of those are in /usr/lib/systemd, often
referenced as %_prefix/lib/systemd). There are also other packages
that ship using %_prefix/lib for the libexecdir because it's hardwired
that way. This situation is more common. That said, I would expect
that these wouldn't come up much, if at all, in Fedora packages in
BRs.
But I don't know how we would deal with a situation where a core
component being referenced is in /usr/lib/foo while the package in
question is being rebuilt as a Flatpak with its /app prefix?
--
真実はいつも一つ!/ Always, there's only one truth!