Re: Why not install pgstattuple by default?
| От | Andrew Dunstan |
|---|---|
| Тема | Re: Why not install pgstattuple by default? |
| Дата | |
| Msg-id | 4DC45536.8000503@dunslane.net обсуждение исходный текст |
| Ответ на | Re: Why not install pgstattuple by default? (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: