Bug 300176 – mail-filter/dspam-3.8.0-r15 wrongly hardcodes lib/share paths for dev-db/postgresql-server-8.4

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Sven Schwyn (svoop) 2010-01-08 16:14:52 UTC]

The dspam ebuild hardcodes lib/share paths e.g. to /usr/lib/postgresql, however, the newer postgresql ebuilds are slotted and store their libs e.g. in /usr/lib/postgresql-8.4. Therefore emerging dspam when postgresql-server-8.4 is installed (and set with eselect) fails with "libpq not found".

As a workaround, you can set two symbolic links:
ln -s /usr/share/postgresql-8.4 /usr/share/postgresql
ln -s /usr/lib/postgresql-8.4 /usr/lib/postgresql

I'm not sure whether this is a bug in the dspam-3.8.0-r15 ebuild (figure out the paths rather than relying on the hardcoded ones) or in the eselect-postgresql-0.3 ebuild (set the above symlinks).

[Comment 1 Marcin Mirosław 2010-07-21 07:58:49 UTC]

I think problem disappeared. In current ebuild we have:
myconf="${myconf} --with-pgsql-includes=/usr/include/postgresql"                                                                      
myconf="${myconf} --with-pgsql-libraries=/usr/$(get_libdir)"

/usr/include/postgres is symlink to /usr/lib/postgres-8.4.
Today i emerge successfully dspam with USE=postgres

[Comment 2 Aaron W. Swenson 2010-07-21 15:20:46 UTC]

First, to be very clear, the issue lies with dev-db/postgresql-BASE, not dev-db/postgresql-server. dev-db/postgresql-server does *not* install the libraries. (Any error regarding libpq is related to dev-db/postgresql-base.)

Second, dev-db/postgresql-server does install some things to /usr/share, but that's not the problem.

Third, when the dev-db/postgresql-base ebuilds were changed to comply to the EAPI2 standard, it failed to take into account the change in blocker behavior. dev-db/postgresql-base-8.4.4-r2, along with the other recent revisions, has taken this issue into account.

Fourth, the solution, as mentioned elsewhere, is to reemerge dev-db/postgresql-base as Portage would have un-merged dev-db/libpq after emerging dev-db/postgresql-base thereby removing pertinent files, like libpq-fe.h.

Finally, and *most* importantly, "hardcoding" the path to /usr/{share,lib,include}/postgresql is the proper behavior. The only time an ebuild should deviate from those generic paths and specify a particular slot is if the package only works with that particular slot.