On 05/06/2011 04:06 PM, Tom Lane wrote:
> Magnus Hagander<magnus@hagander.net> writes:
>> On Fri, May 6, 2011 at 21:19, Andrew Dunstan<andrew@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
