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
_______________________________________________
oi-dev mailing list
[email protected]
http://openindiana.org/mailman/listinfo/oi-dev
