Hi Neal -
Daniel's original suggestion here (make pkg-config always look in /app too) actually seems fine to me and simple, and I don't see any downsides. But certainly flatpak-rpm-macros doesn't *just* modify RPM macros, it currently also:
- Changes the installation prefix for Python by dropping a distutils.cfg
- Adds a configuration file for Maven to change install and search paths
So it's sort of a more general "flatpak-rpm-build" environment. If there was a way to set PKG_CONFIG_PATH globally for the buildroot upon install of the package, that could work too. (Or, yes, we could set FLATPAK_RPM_BUILD and make pkg-config react to that). But how would you do that? mock --chroot doesn't seem to pick things up from /etc/profile.d or /etc/environment.
The only way I can think of doing it would be by configuring rpm.env.* for the Flatpak build tags in Koji, and losing the property that you can "just" drop flatpak-rpm-macros in to get the Flatpak RPM build environment. Do you see any other way?
- Owen
On Thu, Aug 1, 2024 at 7:10 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
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
-- _______________________________________________ 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
