The following is a suggestion for how to make postgresql compatible with possible future native multilib solutions. I will first outline the problem at hand, and then provide a simple and in my opinion decent solution. The problem: the way the current multilib-native approach works is to compile the package for different ABIs, put libraries in their respective directories and wrap binaries with a abi-wrapper that chooses the right version at runtime. It thus relies on src_install to install binaries for different ABIs in the same place. However, this doesn't work with current postgresql installations, because in order to work with eselect-postgresql, they have their binaries installed in /usr/$(get_libdir)/postgresql-${SLOT}/bin. Since this path is obviously ABI-dependant, the abi-wrapper does not work. The solution: after some consideration, I've found a solution that is easy to implement, requires no changes to eselect-postgresql whatsoever and also does not affect users in any way (except when they have /usr/$(get_libdir)/postgresl-${SLOT}/bin hardcoded somewhere, which would then be their own fault, really). The solution is to simply install the binaries to /usr/libexec/postgresql-${SLOT}, which is a nicer place for binaries to reside than /usr/lib anyway, in my opinion. Attached is a patch for postgresql-{base,server}-8.4.2 to demonstrate the solution. I have tested them on my system and so far encountered no obvious problems. Any comments would be highly appreciated. Thanks.
Created attachment 215321 [details, diff] patch for postgresql-{base,server}-8.4.2 for multilib-native compatibility
Something I should probably add: the main reason why we actually need 32bit binaries for postgres is that most build systems and ebuilds depending on postgresql use pg_config --libdir to find the postgresql libraries. If this binary only exists as 64bit, 32bit applications will try to link against 64bit pgsql libs, which of course fails. PS: Apologies for CC'ing the postgresql herd, I was told (too late) that I shouldn't have done this. Won't happen again ;)
Good idea. native-multilib is still a good while away, so there's nothing we can do now. Reopen if it ever becomes a real issue :)
Comment on attachment 215321 [details, diff] patch for postgresql-{base,server}-8.4.2 for multilib-native compatibility Unfortunately, this solution will not work. libexec is reserved for executables that are not meant to be directly invoked by the user or a script. The eselect module is now a bit more sophisticated and can handle multilib, in theory. I will consider this if there is someone that can provide an example of some program that will not work with PostgreSQL, and if there is sufficient demand. Otherwise, I lack the interest in supporting such a setup as I am on 64-bit no-multilib.
*** Bug 589340 has been marked as a duplicate of this bug. ***
