

Andrew Dunstan wrote:
> >For Win32, we could use the registry.  For Unix, we can't use /etc
> >because we can't be sure we are root.  Can we create a dot-file in the
> >user's home directory during install?
> >  
> 
> We can't be sure we are Administrator either.

Exactly. IMHO, using the registry is the worst possible solution, for the
reasons Andrew has already pointed out (ie. multiple installs, user
privileges, ...).


> Binaries can find other binaries the way they do now: look in our own 
> location, then in the path.
> 
> Other files could be found by looking in 1) as per commandline (e.g. -L 
> in initdb) 2) hardcoded location, 3) our-location/../share

I concur (ie. on 2, the hard-coded configure location, which is
c:/msys/1.0/local/pgsql/<etc> on my box, will rarely point to anything
useful on a virgin user machine, and could point to the wrong thing on a
developers machine with multiple installs... hmmm).

I'm yet to see a convincing argument for why we can't adopt the
"binary-location/../share" approach as submitted late March. AFAICS, it was
rejected on the basis that it was not platform independent (no arguments
there) and that we could not rely on the ".." approach. Well, why not? It
would greatly simplify the Win32 installer as users need only nominate where
they want PostgreSQL to live (ie. all it has to do in this regard is dump
the entire pgsql directory structure under a single root, without any
config), and windows users who go and muck with the internal directory
structure of their installed apps don't generally expect their app to
continue working... :-)

The other thing to point out is that, given that it is reasonable to expect
that the vast majority of Windows users won't be rolling their own install,
a solution for this is *needed* for Win32, but is merely a desirable for the
other platforms.

If this idea is to be rejected on the grounds that we'd like a platform
independent solution, then I'd like to see discussion focused in this
regard.

Cheers,
Claudio

--- 
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

Mon, 3 May 2004 13:00:30 +1000 
Claudio Natoli <claudio.natoli@memetrics.com>
Re: Fixed directory locations in installs
Claudio Natoli wrote:
> I'm yet to see a convincing argument for why we can't adopt the
> "binary-location/../share" approach as submitted late March. AFAICS,
> it was rejected on the basis that it was not platform independent (no
> arguments there) and that we could not rely on the ".." approach.

The only objection was that it hardcodes the layout already in the 
source, which gives us no flexibility at all to try out different 
installation layouts.  If you want to compute the relative paths from 
bindir to libdir etc. at build time based on actual configure options, 
then I see no problem with that.


Mon, 3 May 2004 08:59:04 +0200
Peter Eisentraut <peter_e@gmx.net>
Re: Fixed directory locations in installs