On Tue, Jul 9, 2024 at 9:38 AM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:
>
> There have been a number of PRs[1] opened to workaround problems
> with pkg-config not finding .pc files when dependencies have
> been built in flatpak context.
>
> Normally pkg-config would always find .pc files in any system
> dirs. ie
>
> /usr/local/lib64/pkgconfig
> /usr/local/share/pkgconfig
> /usr/lib64/pkgconfig
> /usr/share/pkgconfig
>
> but when a package is built as a flatpak, there are additional
> system dirs defined
>
> /app/lib64/pkgconfig
> /app/share/pkgconfig
>
> and an apps' .pc files go into /app, rather than /usr.
> pkg-config / pkgconf is not searching those by default.
>
> flatpkg-rpm-macros overrides the definition of %___build_pre
> to set PKG_CONFIG_PATH to point to the /app tree.
>
> This only works when cases where pkg-config is invoked under
> the RPM %build section. Fine for the normal build process
> stage.
>
> It fails, though, if an RPM spec needs to call pkg-config
> separately from %build. eg if doing
>
> %define wireshark_plugindir %(pkg-config --variable plugindir wireshark)/epan
>
>
> The proposed fix in the PRs is to add a call to %___build_pre
> for any invokation of 'pkg-config' in spec files.
>
> Functionally that works, but to me this feels like a suboptimal
> approach.
>
> I tend to view /app/{lib64,share}/pkgconfig as being standard
> system libdirs, and thus would expect pkg-config to automatically
> search them, without requiring PKG_CONFIG_PATH to be set.
>
> Is there a reason we can't build pkgconfig such that it includes
> the /app dirs out of the box.
>
> AFAICT, such a change should not negatively affect normal Fedora
> builds since the /app dirs won't exist, and would make pkg-config
> "do the right thing" in Flatpak context, avoiding whack-a-mole
> fixing of RPMs to call %___build_pre
>
> Incidentally is %___build_pre a macro we can rely on long term ?
>
> Is there any rule for what the different number of leading "_"
> mean in macros ? ie are macros with three leading _ still fair
> game to reference in specs, or are they considered an unstable
> impl detail that's subject to change ?
>
Note that pkg-config(1) is already a wrapper:
https://src.fedoraproject.org/rpms/pkgconf/blob/rawhide/f/pkg-config.in
It points to a multi-arch wrapper too:
https://src.fedoraproject.org/rpms/pkgconf/blob/rawhide/f/platform-pkg-config.in
If there's a variable that always exists when building Flatpaks, we
can use that to automatically reconfigure the PKG_CONFIG_PATH as
appropriate.
If such a variable doesn't already exist, we should add something to
make it so, because Flatpak builds have enough differences that it's
useful to be able to propagate that into the build environment anyway.
--
真実はいつも一つ！/ Always, there's only one truth!
--
_______________________________________________
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
