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.
I've made a wiki pages that has all the changes I've needed so far:
https://fedoraproject.org/wiki/Flatpak:Fixes
Everything marked with a checkmark is already in Fedora - either because I committed a fix directly (mostly workstation related packages), or more commonly, because I've submitted a pull-request that the maintainer accepted.
Regards, Owen
On Mon, Oct 1, 2018 at 12:16 PM Owen Taylor otaylor@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?
On Mon, Oct 1, 2018 at 7:26 PM Neal Gompa ngompa13@gmail.com wrote:
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?
I think you are saying that my statement above " %{_prefix} and related macros specify the install location of this package, they should not be used for paths to tools used as BuildRequires." is only a negative statement - it doesn't say what you *should* use for paths to tools.
My experience is that - for graphical applications and the libraries and runtimes they use - the number of times an absolute path to a dependency is needed in a spec file and not covered by a macro is small. In the ~120 packages I've tried building with prefix=/app, I've hit this twice:
* In the endless-sky package, scons is invoked as '%{_bindir}/scons * In the SDL package, it copies %{_datadir}/automake-*/config.{sub,guess} into the project
And in fact, the first could be handled by simply counting on $PATH and running 'scons'. My recommnedation for the second is to use /usr/share/automake-*/config.{sub,guess}. We're not going to move the FHS directories around in Fedora in any forseeable future - we're not going to change /usr to /user. And rebuilding the entire set of Fedora packages with a different %_prefix is not particularly useful - it's more useful to build one or a small subset of packages with a different %_prefix. So the assumption should be that tool X was installed in the standard Fedora location. But that's an assumption that it's not necessary to make very often.
Owen
packaging@lists.fedoraproject.org
-
Neal Gompa -
Owen Taylor