Re: [ANNOUNCE] i386 RPMs available for v6.5.1
От | Thomas Lockhart |
---|---|
Тема | Re: [ANNOUNCE] i386 RPMs available for v6.5.1 |
Дата | |
Msg-id | 379DDA55.D5F9FEB0@alumni.caltech.edu обсуждение исходный текст |
Ответы |
Re: [ANNOUNCE] i386 RPMs available for v6.5.1
(Rich Shepard <rshepard@appl-ecosys.com>)
|
Список | pgsql-hackers |
(back on list, since this is a topic of general RH interest imho) > > I've posted RPMs for v6.5.1 at > I'm curious why the rpm installs place postgres files in different > directories than does the .tgz source files. When I installed 6.4.2, I had > all sorts of problems with the rpm version because it wouldn't let me define > and use my own data directories (e.g., ~/data/accounting). I finally figured > out how to configure, make and install the source according to the > Administrator's Guide. RPMs install files into /usr/{bin,lib} and /var/lib/pgsql because these same (or similar) RPMs are shipped by RedHat as part of their distribution. RH feels constrained to *only* install binaries, libraries, etc, into the "standard places" which leaves no room for alternatives. As you may know, file system layout has been a hot topic for Linux standardization, and there isn't much point in trying to fight it, or trying to push RH away from their choices ;) It would be possible to build RPMs which install into the areas documented directly in Postgres, but imho that is not helping by much, since on different (non-Linux) systems the best locations will, in general, vary, and RH is just an example of that. Now that we can generate our own RPMs, we can do a better job of documenting the RPM behavior. Before, that was a RH black box. I *believe* that the v6.5.x RPMs will allow you to define your data directories, but I agree that it isn't clear how to do this. fyi, the way to do this is to use initdb with PGDATA pointed at your desired target directory. You might try using "initlocation" to prepare that target directory, or you can do this manually. For the RH installation, set the protections and ownership the same as for /var/lib/pgsql; your postgres account needs to own the directory and the protections should be 700. You would also modify /etc/rc.d/init.d/postgresql.init to point to the right place. > Now I'm ready to do some serious porting of my DOS-based business > applicaitons. I'm going to use GTK+ for the GUI, C for the glue and I think > that I ought to upgrade to 6.5.1 from the present 6.4.2. But, I hesitate. > Postgres appears to function now and I don't want to spend more time > floundering around trying to get 6.5.1 up and running instead. > So, my question: should I grab the 6.5.1 .tgz file and follow the steps I > used for the 6.4.2 installation rather than using the package? imho, the RPMs are most appropriate for casual users or small installations, but I think that they could be used successfully in a large installation too. Especially as you deploy production servers, the flexibility you get by a from-source installation is not as important, and the convenience of an easy installation process is more important. A from-source installation gives you the most control over (server) installation issues, and more importantly would let you more easily apply workaround patches during the lifetime of that version. I'd suggest using a from-source when doing development, and the RPMs when deploying, but that is just me... The RPMs seem to me to be entirely appropriate for any and all client-only installations, for both small and large configurations. With a bit more docs, the RPM installation can be (almost) as flexible as a from-source installation (but the target locations are afaik pretty fixed). If you (or anyone else) would like to do the RPM installation for v6.5.1 to upgrade your v6.4.2 system, I'd be happy to help walk you through it, and we can capture that info for the next round of docs. Regards. - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
В списке pgsql-hackers по дате отправления:
Следующее
От: Thomas LockhartДата:
Сообщение: Re: [CORE] Re: [Keystone Slip # 22] Some confusion with datetimedata type andtimezone