Re: RPM changes for 7.1.
От | Peter Eisentraut |
---|---|
Тема | Re: RPM changes for 7.1. |
Дата | |
Msg-id | Pine.LNX.4.30.0012132035410.1277-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: RPM changes for 7.1. (Lamar Owen <lamar.owen@wgcr.org>) |
Список | pgsql-ports |
> We already have the problem with postgresql-tk -- the pgaccess docs get > placed in the postgresql-tk-x.y.z directory under the docs. I find it somewhat odd that pgaccess is thrown together with pgtksh. Mostly they have nothing to do with each other besides both being somehow connected with Tcl/Tk. That's like a postgresql-c package: nonsense. Similarly, I find it not useful that PL/Perl and thrown together with Pg.pm, and PL/Tcl is thrown together with pgtclsh. Maybe you want to make a separate postgresql-server-{perl,tcl} package. I think you already suggested that. > However, I am not leaning towards a separate docs subpackage -- it was > suggested to me, and I placed it on my list for discussion. I don't think this is a bad idea. Maybe people only want to install the docs once in their network and make them available via a web server. I did it that way. > Making the postgresql package depend upon the postgresql-libs package is > easy enough. That means you do have at leats two packages to install. (On a quiet night you can hear the Debian users laughing...) > One example of a split that seems to work well (AFAIK) is the amanda > network backup tool. > The main package contains files common to the client and server. In PostgreSQL there are, strictly speaking, no files in common to client and server. Two more points: * createlang, droplang, and pg_id should be in the server package. * Maybe you want to create a postgresql-server-devel package with the backend header files. These are needed rather seldom. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
В списке pgsql-ports по дате отправления: