Re: Spec file fixes for prefix=/app Flatpak builds

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Oct 1, 2018 at 12:16 PM Owen Taylor <otaylor@xxxxxxxxxx> 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!
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux