Обсуждение: pgNixInstaller: Making PostgreSQL relocatable
Hi, We have been having a short talk with Devrim this evening about the pgnixInstaller[1] project he started[2] a while ago. I have briefly read over the thread following the project announce, particularly comments on issues about package systems of distributions and integration with them. I believe the project will add some value to the PostgreSQL community, so I'd like to join and add my grain of salt. Main goal of the project appears to be making installation and configuration of PostgreSQL server a no-brainer, not easier. Any moron you can get to the /mouse/[3] should be able to get PostgreSQL up and running in some short time period. And that moron should be able to do it in some fashion that's not so good, but the installation should work. Fortunately we're not alone in the universe, several other projects suffered from the very same problem. Including the much larger OpenOffice.org project. I think some of you have installed it on your favorite Unix-alike OS using it's click-click-and-go installer, when distributions did not have packages of it -- ancient times. We'll be doing that for PostgreSQL, I think it's a fantastic way for me to get involved. In order to achieve this *properly*, I intend to make PostgreSQL relocatable, that is, PostgreSQL should be able to run if you `copy` it's binaries somewhere else -- no matter where you `./configure --prefix`ed it. I took a very quick look at some parts of the codebase and it seems doable to me. Apparently we'll be avoiding package systems integration and development-packages-requirement issues mentioned in the thread. Next step would be a simple, possibly shell-script and xdialog/zenity[4] based prototype installer. I personally can't afford the Python thing, Solaris and possibly others don't have it yet and embedding Python in a shell script is not the brightest idea obviously. Now the question, would you accept patches for this, or are we going to maintain some set of patches? May you have suggestions about any other direction, I'd be more than happy to know. Cheers, [1] http://pgfoundry.org/projects/pgnixinstaller/ [2] http://archives.postgresql.org/pgsql-hackers/2006-01/msg00943.php [3] http://www.joelonsoftware.com/articles/fog0000000024.html -- Enver
Hey, Enver ALTIN wrote: > Next step would be a simple, possibly shell-script and xdialog/zenity[4] > based prototype installer. I personally can't afford the Python thing, > Solaris and possibly others don't have it yet and embedding Python in a > shell script is not the brightest idea obviously. [4] http://cvs.gnome.org/viewcvs/zenity/ :) -- Enver
Enver ALTIN <ealtin@parkyeri.com> writes:
> In order to achieve this *properly*, I intend to make PostgreSQL
> relocatable, that is, PostgreSQL should be able to run if you `copy`
> it's binaries somewhere else -- no matter where you `./configure
> --prefix`ed it. I took a very quick look at some parts of the codebase
> and it seems doable to me.
s/doable/already done/, no?
regards, tom lane
Hi Tom, Tom Lane wrote: > Enver ALTIN <ealtin@parkyeri.com> writes: >> In order to achieve this *properly*, I intend to make PostgreSQL >> relocatable, that is, PostgreSQL should be able to run if you `copy` >> it's binaries somewhere else -- no matter where you `./configure >> --prefix`ed it. I took a very quick look at some parts of the codebase >> and it seems doable to me. > > s/doable/already done/, no? I did a Google search on "relocatable PostgreSQL" and the first result[1] said it's already done. Apparently it didn't work for me on Solaris 8 (linking problems). I'll be looking at it sometime today. Thanks for your immediate response :) [1] http://www.postgresql.org/docs/faqs.TODO.html -- Enver
Enver ALTIN <ealtin@parkyeri.com> writes:
> Tom Lane wrote:
>> s/doable/already done/, no?
> I did a Google search on "relocatable PostgreSQL" and the first
> result[1] said it's already done. Apparently it didn't work for me on
> Solaris 8 (linking problems). I'll be looking at it sometime today.
OK ... it's supposed to work to shift the whole installation tree to
a new root, ie, paths to places like the /share and /lib directories
are determined relative to where the backend executable actually is.
If this is not working on Solaris then for sure we want to know ...
regards, tom lane
Enver, > Fortunately we're not alone in the universe, several other projects > suffered from the very same problem. Including the much larger > OpenOffice.org project. Are you crossing over from OpenOffice.org? Hi! I'm former OOo now PG and likely to get involved with OOo again very soon ... -- Josh Berkus Aglio Database Solutions San Francisco
Tom Lane <tgl@sss.pgh.pa.us> writes: > Enver ALTIN <ealtin@parkyeri.com> writes: > > Tom Lane wrote: > >> s/doable/already done/, no? > > > I did a Google search on "relocatable PostgreSQL" and the first > > result[1] said it's already done. Apparently it didn't work for me on > > Solaris 8 (linking problems). I'll be looking at it sometime today. > > OK ... it's supposed to work to shift the whole installation tree to > a new root, ie, paths to places like the /share and /lib directories > are determined relative to where the backend executable actually is. > If this is not working on Solaris then for sure we want to know ... I'm sure this isn't the only possible gotcha but I do seem to recall that on Solaris there's no such thing as a default LD_LIBRARY_PATH. Every binary stores absolute paths to every shared library it's linked against. -- greg
On Mar 23, 2006, at 12:15 AM, Tom Lane wrote: > OK ... it's supposed to work to shift the whole installation tree to > a new root, ie, paths to places like the /share and /lib directories > are determined relative to where the backend executable actually is. > If this is not working on Solaris then for sure we want to know ... It is not relocatable on OS X. The full prefix path seems to be used instead. For example: [M:bin/postgresql/bin] % otool -L pg_ctl pg_ctl: /sw/bin/postgresql-8.1.2/lib/libpq.4.dylib (compatibility version 4.0.0, current version 4.1.0) /usr/lib/libssl.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7) /usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 369.1.5) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.2) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 92.0.0) It would be really nice to have relative references. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL
Greg Stark wrote: > I'm sure this isn't the only possible gotcha but I do seem to recall > that on Solaris there's no such thing as a default LD_LIBRARY_PATH. > Every binary stores absolute paths to every shared library it's > linked against. On Solaris you can actually use relative library paths by writing $ORIGIN in the path. We don't do that right now, but it's possible. -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Thu, Mar 23, 2006 at 07:47:13PM -0500, John DeSoi wrote: > > On Mar 23, 2006, at 12:15 AM, Tom Lane wrote: > > >OK ... it's supposed to work to shift the whole installation tree to > >a new root, ie, paths to places like the /share and /lib directories > >are determined relative to where the backend executable actually is. > >If this is not working on Solaris then for sure we want to know ... > > It is not relocatable on OS X. The full prefix path seems to be used > instead. For example: I don't understand. Dynamic linkers have for years been smart enough to find libraries by themselves. Fixed paths are a pain, which is why Debian forbids the use of RPATH for example. Anyway, looking at the manpage of otool it doesn't say that it just prints the raw name, so perhaps it's doing the same as ldd. To be sure you'd need to strings the binary to see what it says. http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/otool.1.html Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
On Mar 24, 2006, at 7:25 AM, Martijn van Oosterhout wrote: > Anyway, looking at the manpage of otool it doesn't say that it just > prints the raw name, so perhaps it's doing the same as ldd. To be sure > you'd need to strings the binary to see what it says. Yes, strings shows the full path of prefix provided to configure. And I can tell you from experience it is not relocatable :). Here is a bug I recently filed for pgAdmin which discusses the use of install_name_tool to make the reference relative. Certainly it would be better if they could be compiled with relative references, but at least I found a solution without having to understand gcc. http://www.pgadmin.org/archives/pgadmin-support/2006-03/msg00053.php John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL