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>
