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).
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
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.
