On Thu, Aug 01, 2024 at 07:09:56AM -0400, Neal Gompa 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.
The current solution provided by flatpak-rpm-macros uses env vars
set in %__build_pre, which is unreliable because %__build_pre isn't
always used in all places which invoke pkg-config.
A different env approach would need to be setting something in
/etc/profile I guess, but at that point it might as well just
carry on setting PKG_CONFIG_PATH directly except that various
places a liable to blindly override PKG_CONFIG_PATH
That's why I was thinking that a more reliable way would be for
pkgconf to direclty check the existance of flatpak system dirs
if test -d /app/lib64/pkgconfig
...add to pkgconfig system path....
if test -d /app/share/pkgconfig
...add to pkgconfig system path....
thus if something pulled in via BuildRequires has used /app instead
of /usr, then pkgconfig would "do the right thing" with this new
system path location, without concern over env vars being propagated
in all the right places.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
--
_______________________________________________
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
