Summary: | mail-filter/dspam-3.8.0-r15 wrongly hardcodes lib/share paths for dev-db/postgresql-server-8.4 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Sven Schwyn (svoop) <gentoo> |
Component: | Current packages | Assignee: | Net-Mail Packages <net-mail+disabled> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | bug, titanofold |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Sven Schwyn (svoop)
2010-01-08 16:14:52 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 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. |