libpq is already slotted and dev-db/libpq-8.2.4 installs libpq.so.5. Therefore the upgrade requires a rebuild (which revdep-rebuild finds) of all installed packages using libpq. If libpq-8.2.4 were placed in slot 5, existing client applications would not need to be immediately rebuilt but continue to use libpq.so.4 and will still communicate with the server running 8.2.x.
Slotted postgresql won't get into the tree now. Needs more testing and work in the overlay.
Related to this, dev-dev/libpq-8.2.4 installs /usr/lib/libpq-5.a, but installs a symlink libpq.a -> libpq-${SLOT}.a, ie. in this case libpq-4.a which doesn't exist.
after a friend lamenting to me the exact same problem I decided I would just stop using pdns to get around, I decided to look into the problem a bit further. cat /usr/portage/dev-db/libpq/libpq-8.2.4.ebuild <--snip--> SLOT="4" <--snip--> src_install() { <--snip--> dosym libpq-${SLOT}.a /usr/$(get_libdir)/libpq.a <--snip--> file /usr/lib/libpq.a /usr/lib/libpq.a: broken symbolic link to `libpq-4.a' qlist libpq | grep "\/libpq\...." /usr/lib/libpq.so.5.0 /usr/lib/debug/usr/lib/libpq.so.5.0.debug /usr/lib/libpq.so.5 hmm. No libpq-4. funny that. <pkgmetadata> <herd>postgresql</herd> </pkgmetadata> Assign Plz ? THeres about 3 different easy ways to get around this problem of course ;) Just needs somebody with commit rights to choose which is most sane and get it done :)
This bug is about slotted postgresql; if you have issues with libpq, file a *new* bug please. Thanks.
Doesn't get any later than this. Package no longer exists.
