[oi-dev] PostgreSQL question

[Alexander Pyhalov]

On 10/21/2013 18:42, Alexander Pyhalov wrote:
> Hello.
> I have a question on PostgreSQL 8.4 packaging.
> Currently we have disabled runpath for PG and ship postgres-common
> package which contains libpq. But what if we ship several PG versions?
> Are we sure in binary compatibility of, let's say, 9.2 libpq  and  8.4
> clients?
>
> I just would like to estimate pros and cons of removing
> "--disable-rpath" switch.
>
> I'd like to remove it (so that each PostgreSQL binary has correct
> embedded rpath) , ship almost empty postgres-common package (containing
> only user and group definitions) and make /usr/postgres/{bin,lib},
> /usr/bin/psql, /usr/lib/libpq.so mediated links (or perhaps even avoid
> shipping /usr/lib/libpq.so by default). For example, currently mysql
> doesn't ship libraries in /usr/lib.
>
> What do you think?

So, the first package version is available here:
https://github.com/pyhalov/oi-userland/compare/postgresql84

Please, review.

Packages (besides postgresql itself) that can be affected (currently not 
in oi-userland):
pkg:/database/postgres/library/c++/libpqxx
pkg:/database/postgres/pgtcl
pkg:/library/perl-5/dbd-pgsql

Packages that can be affected but are easy to rebuild:
pkg:/library/apr-util/dbd-pgsql
pkg:/web/php-54/extension/php-pgsql

Distinctions from original package:
1) RPATH is embedded in utilities and libraries
2) /usr/lib/libpq* and /usr/lib/amd64/libpq* are links to 
/usr/postgres/8.4/lib/ versions of libraries. Facet facet.compat.dev is 
set on these links
3) uids and gids definition are moved to postgres-common. It contains 
only them and /usr/lib/*/libpq* links.
4) sysconfdir changed from /etc/postgres/ to /etc/postgres/8.4. (I 
think, there are not many people who use configs in /etc/postgres for 
PostgreSQL)
5) pg_config adds rpath by default (pg_config --ldflags)

Testing done:
1) created db, played with it a bit
2) checked php pgsql extension - seems to work
3) checked libpqxx with Sun Studio CC - seems to work
4) gmake check - timestamptz test fails (I've seen this before, it seems 
to be expected on OI)

As for earlier postgres versions, I think they be easily marked obsolete 
after postgres 8.4 integration, however it's not a high priority task. 
I'd better look at PG 9.3 / 9.2.
-- 
Best regards,
Alexander Pyhalov,
system administrator of Computer Center of Southern Federal University