Re: 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(at)parkyeri(dot)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(at)parkyeri(dot)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(at)parkyeri(dot)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(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Enver ALTIN <ealtin(at)parkyeri(dot)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(at)svana(dot)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