Re: flatpak vs pkg-config system libdir

[Owen Taylor <otaylor@xxxxxxxxxx>]

On Fri, Aug 2, 2024 at 8:31 AM Cristian Le via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

On 2024/08/01 17:27, Owen Taylor wrote:

On Thu, Aug 1, 2024 at 9:24 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote:

Well, if you have a general package that's shipped in every buildroot
for flatpak builds, you can ship your own wrapper, and I can make it
check if RPM_BUILD_ROOT is defined *and* this file exists, it would
redirect to that wrapper automatically. Or some variation of this.

We used to do something similar for MinGW, I believe, so I think it'd work.

So, basically, your proposal is that we patch the pkg-config package so that if /etc/flatpak-rpm-build exists then we set a default PKG_CONFIG_PATH that includes /app? What's the advantage over just adding /app unconditionally?

- Owen

I am rather weary about this, if the idea is to make this applicable to users as well. Let's say we have two flatpak apps which both have a public dependency of a common dependency (let's say they both contain `#include` on a header from there), but the versions are different in each. How would `/app/lib64/pkgconfig` deal with having both apps installed (granted I am not familiar with this part of flatpaks).

/app/lib64/pkgconfig is something that is only populated within the build environment - if you are building a Flatpak in Fedora and it wants libmediaart, then there is a rebuild:

 https://koji.fedoraproject.org/koji/buildinfo?buildID=2439939

tagged into f40-flatpak-app. When a Flatpak app is built in Koji (or locally during development), a repository is used that prefers these rebuilds to the normal Fedora Flatpaks, and so a libmediaart-devel is pulled in that has it's PC file in /app/lib64/pkgconfig. But that libmedia-devel is *not* part of the normal Fedora repositories.

Typically, any two Flatpaks built against F40 will bundle the same library rebuilds (this is a change from F38 and earlier where each Flatpak had its own module and there could be separate builds), but at runtime, while identical files are shared behind the scenes using ostree, there is complete isolation of the filesystems and they could perfectly well have different versions of a library and it wouldn't break anything.

The more concerning part is if a random app unnecessarily exposes a dependency's .pc files, e.g. if the dependency was included via CMake's `add_subdirectory` and the installation of the dependency was not guarded by a `<PROJECT>_INSTALL` option. Then the user might get some surprises when they try to build something locally, particularly since the order of preference between `/usr/lib64` and `/app/lib64` is unclear.

 Any files from a flatpak rebuild bundled with an application will be within that applications sandbox and not exposed to builds on the host.

If it's limited to building within the spec file, then it is more understandable, but at that point shouldn't it still be handled within `flatpkg-rpm-macros`?

The  issue here is that RPM macros can only affect the environment during the %build step - but sometimes pkg-config gets used in say, a macro definition (see the first post in this thread), and how do you handle that? SInce /app/lib64/pkgconfig *only* exists when building Flatpaks, it seems fairly reasonable to say "if /app/lib64/pkgconfig exists, then look there" rather than "if /etc/this-is-a-flatpak-build exists, look in /app/lib64/pkgconfig".

- Owen

 

-- 
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue