The pkg-config program expect to find its *.pc files in /usr/$(get_libdir)/pkgconfig. And in fact this is where postgresql would install them by default: src/Makefile.shlib:pkgconfigdir = $(libdir)/pkgconfig But, since we're slotting postgres, we have in the ebuild, --prefix="${PO}/usr/$(get_libdir)/postgresql-${SLOT}" This causes the *.pc files to wind up in, $ ls /usr/lib/postgresql/pkgconfig/ total 16K -rw-r--r-- 1 root root 289 2014-02-25 17:49 libecpg_compat.pc -rw-r--r-- 1 root root 261 2014-02-25 17:49 libecpg.pc -rw-r--r-- 1 root root 244 2014-02-25 17:49 libpgtypes.pc -rw-r--r-- 1 root root 258 2014-02-25 17:49 libpq.pc but pkg-config can't find them there. I'm by no means an expert with pkg-config, but I'm working on an ebuild for pgmodeler (bug #459918), and it would make things easier if pkg-config would work automatically. So hopefully you can take a look and see if my guess is right!
one way to accompilish this without moving the files, if that is what is required: to ebuild... echo "PKG_CONFIG_PATH=\"${EPREFIX}/usr/$(get_libdir)/postgresql/pkgconfig\"" > "${T}"/99postgresql doenvd "${T}"/99postgresql and user does... env-update source /etc/profile
Well, that's new. I missed the pkg-config files being added. Typically PostgreSQL-related packages use pg_config, and I'd recommend using that instead as it'll be at least a month before we could guarantee user systems that are up to date will work properly with the .pc files.
Unfortunately the details are buried in a Qt5 build system that I don't understand. I was able to make pkg-config work by appending /usr/lib/postgresql/pkgconfig to PKG_CONFIG_PATH, so it's not a show stopper. Just a little ugly in the ebuild. The dependency on Qt5 means it won't be a candidate for gx86 for a while anyway.
I'm looking at this again just out of curiosity, and I think Samuli's solution is probably the best way to fix this. Postgres is going to remain slotted, and we want newly-built packages to build against the eselected version of Postgres, so we want the *.pc files from that version to be the ones that get used. Rather than do gymnastics with symlinks to the individual *.pc files, we might as well just append the "current" Postgres pkgconfig path to PKG_CONFIG_PATH. By doing echo "PKG_CONFIG_PATH=\"${EPREFIX}..." you achieve the benefit of having EPREFIX available which you wouldn't if a static env.d file was added to $FILESDIR. That only leaves the choice of where it should go: env.d/50postgresql used to belong to eselect-postgresql, but now it's gone. So it doesn't really matter but that seems as good a place as any to create and install the env.d file. Here's a patch to eselect-postgresql that seems to do what it's supposed to: --- a/app-admin/eselect-postgresql/eselect-postgresql-1.2.1.ebuild +++ b/app-admin/eselect-postgresql/eselect-postgresql-1.2.1.ebuild @@ -4,6 +4,8 @@ EAPI="5" +inherit multilib + DESCRIPTION="Utility to select the default PostgreSQL slot" HOMEPAGE="http://www.gentoo.org/" SRC_URI="http://dev.gentoo.org/~titanofold/${P}.tbz2" @@ -21,6 +23,14 @@ src_install() { doins postgresql.eselect dosym /usr/bin/eselect /usr/bin/postgresql-config + + # Create an env.d file that will append the currently-selected + # Postgres's pkgconfig path to the PKG_CONFIG_PATH environment + # variable. See bug #512236. + local pcp="${EPREFIX}/usr/$(get_libdir)/postgresql/pkgconfig" + echo "PKG_CONFIG_PATH=\"${pcp}\"" > "${T}"/99postgresql + + doenvd "${T}"/99postgresql } pkg_postinst() {
(In reply to Michael Orlitzky from comment #4) > I'm looking at this again just out of curiosity, and I think Samuli's > solution is probably the best way to fix this. Postgres is going to remain > slotted, and we want newly-built packages to build against the eselected > version of Postgres, so we want the *.pc files from that version to be the > ones that get used. > > Rather than do gymnastics with symlinks to the individual *.pc files, we > might as well just append the "current" Postgres pkgconfig path to > PKG_CONFIG_PATH. > > By doing echo "PKG_CONFIG_PATH=\"${EPREFIX}..." you achieve the benefit of > having EPREFIX available which you wouldn't if a static env.d file was added > to $FILESDIR. That only leaves the choice of where it should go: > env.d/50postgresql used to belong to eselect-postgresql, but now it's gone. > So it doesn't really matter but that seems as good a place as any to create > and install the env.d file. > > Here's a patch to eselect-postgresql that seems to do what it's supposed to: > > --- a/app-admin/eselect-postgresql/eselect-postgresql-1.2.1.ebuild > +++ b/app-admin/eselect-postgresql/eselect-postgresql-1.2.1.ebuild > @@ -4,6 +4,8 @@ > > EAPI="5" > > +inherit multilib > + > DESCRIPTION="Utility to select the default PostgreSQL slot" > HOMEPAGE="http://www.gentoo.org/" > SRC_URI="http://dev.gentoo.org/~titanofold/${P}.tbz2" > @@ -21,6 +23,14 @@ src_install() { > doins postgresql.eselect > > dosym /usr/bin/eselect /usr/bin/postgresql-config > + > + # Create an env.d file that will append the currently-selected > + # Postgres's pkgconfig path to the PKG_CONFIG_PATH environment > + # variable. See bug #512236. > + local pcp="${EPREFIX}/usr/$(get_libdir)/postgresql/pkgconfig" > + echo "PKG_CONFIG_PATH=\"${pcp}\"" > "${T}"/99postgresql > + > + doenvd "${T}"/99postgresql > } > > pkg_postinst() { Thank's for the work. However, the work was done in the wrong place. It should be done in postgresql.eselect as I believe that environment file would be overwritten by it.
postgresql.eselect writes the (slot-specific) LDPATH and MANPATH to /etc/env.d/50postgresql. Thanks to a symlink, the addition to PKG_CONFIG_PATH doesn't need to change when the user switches slots. So it can go in a static file (99postgresql) that will be sourced in addition to the 50postgresql generated by postgresql.eselect. You wind up with an extra env.d file, but it separates the static variables from the ones that eselect generates. If you'd prefer to set the PKG_CONFIG_PATH in postgresql.eselect anyway, I can make it work the same way as the other variables and append the direct path to the pkgconfig dir (with the version number in the path).
In fact, both /usr/share/postgresql and /usr/lib/postgresql are symlinks managed by eselect-postgresql, so there's no reason (I don't think?) to recreate the env.d file every time the user switches slots. Pointing LDPATH and MANPATH at the symlink should work as well. If not, I guess we should at least be consistent about it and do PKG_CONFIG_PATH in the same place.
Packaged dev-haskell/postgresql-simple in ::haskell overlay today and was surprised by broken pkg-config paths.
I can't get libpq path for pgmodeler. $: pkg-config libpq --cflags --libs Package libpq was not found in the pkg-config search path. Perhaps you should add the directory containing `libpq.pc' to the PKG_CONFIG_PATH environment variable No package 'libpq' found
The issue is still actual with 9.5.3 :(
ping?
it is 9.6 release already, but bug is still in place. // and eselect-postgresql looks untouched for almost year already :(
This issue has been addressed in my overlay with the introduction of a new eselect module. There may be a couple minor changes made before it gets introduced to the tree, but it should be ready for real work unless the lot of you find any glaring issues. https://github.com/titanofold/titanofold-gentoo-x86
commit 96fb4f98f5c23f3454f501efae669f7584f98568 Author: Aaron W. Swenson <titanofold@gentoo.org> Date: Wed Apr 12 11:31:54 2017 -0400 app-eselect/eselect-postgresql: Bug Fixes and Enhancements Version 2.0 is capable of handling the upcoming change in versioning for PostgreSQL. Links to pkg-config files of the selected slot are now created and managed by this module. Links to the man pages for the selected slot are now created and managed by this module. Slot-specific man pages are handled by the ebuilds. This version is stateless. It does not need to store any files to determine which slots and links are in use. Bugs: 597564, 512236, 564512
