Re: Relocatable installs - Mailing list pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > My idea is to write a /port function that uses various methods to find
> > the needed files.  We could look in the relative location first, and if
> > the needed file is not found, look in the hardcoded directory.
> 
> I think a "search until you find something" approach would be a really
> bad idea.  Particularly on a machine with multiple PG versions installed
> (and that has surely got to be a likely situation for people who are
> wanting to move things around).  It seems entirely too likely that you
> would find the wrong version of some file.

As I see it, we do two searches.  One is for the path to our own binary,
and the second is a search for another binary or the /lib or /share
directories.

In initdb and postgres, we do searches by breaking up the $PATH value,
and testing for versions.  In pg_dump, we just run system() (uses
default PATH), and then try hardcoded path if that fails, with no
version checking.  This should all be consistent at least.

Then, once we find our own path, the next question is how to handle
looking for lib and share, and whether we look for a directory name, or
specific file, and can we check versions?  Right now we do none of
these, I think.  We just go for hard-coded.

> So ISTM that the location in which a given installation looks for its
> associated files should be completely predictable and *not* depend on
> whether it finds something there.

Ah, got it.  Makes sense.  We do searches for finding our own path, but
you can argue that this predictable --- we know we are running so the
binary must be somewhere.  :-)  However, the version checking we do now
is a little non-predictable because if we find a binary of the wrong
version, we keep looking in the path.

> I'm fine with offering an option to make that location be relative to
> where the executable came from.  But not with nondeterminism.

Ah, makes sense.

> I think we should use the relative-path method *unless* the configure
> command called out specific installation directories (that is, not
> just --prefix but --datadir and/or related options).  If you use one of
> those then that absolute path should be used always, ie, you are
> specifically asking for a nonrelocatable install and that's what you
> should get.

That would make my job very easy.  If they specify lib or share with a
unique path, it is hard to imagine how they would tar up the install
anyway because it would be usually mixed into their operating system
directories.  Are others OK with this?  You can still specify --prefix,
but if you override the other default directories, the program will use
those hard-coded ones rather than ones relative to your /bin.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073