On 05/06/2011 04:06 PM, Tom Lane wrote:
Magnus Hagander<mag...@hagander.net> writes:
On Fri, May 6, 2011 at 21:19, Andrew Dunstan<and...@dunslane.net> wrote:
On 05/06/2011 03:14 PM, Christopher Browne wrote:
If there's a "server" package and a "client" package, it likely only
fits with the "server" package. On a host where only the "client" is
installed, they won't be able to install extensions, so it's pretty
futile to have it there.
I don't agree. It can be useful even there, to see how the libraries are
configured, for example. I'd be inclined to bundle it with postgresql-libs
or the moral equivalent.
+1.
Well, actually, I think packagers have generally put it into a -devel
subpackage. If it were in either a "server" or "client" package there
would be much less of an issue.
Bundling pg_config into a -libs package is probably not going to happen,
at least not on Red Hat systems, because it would create multilib issues
(ie, you're supposed to be able to install 32-bit and 64-bit libraries
concurrently, but there's noplace to put a /usr/bin file without causing
a conflict).
FWIW, I did move pg_config from -devel to the "main" (really client)
postgresql package in Fedora, as of 9.0. That will ensure it's present
in either client or server installations. Eventually that packaging
will reach RHEL ...
That's reasonable, and certainly better than having it in -devel.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
