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 <ngomp...@gmail.com> wrote:
> On Tue, Jul 9, 2024 at 9:38 AM Daniel P. Berrangé <berra...@redhat.com>
> 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
