Thread: Fixed directory locations in installs

Fixed directory locations in installs

From
Bruce Momjian
Date:
I have been looking at our use of fixed directory specifications in
binaries.

Right now we have libdir (dynamic_library_path) predefined in the
compile, with a GUC to override it.  initdb also needs to be able to
find its input files, and that can be overridden by an initdb flag.

Adding the timezone database, backends now need to know where /share is,
not just initdb.  Seems we need a new GUC variable for that too.

Also, Win32 installs are going to want to be more directory independent
than Unix.

Right now if we move /lib or (or in the future /share) we need to edit
postgresql.conf.  Is there an easier way to do this?  Should initdb be
setting libdir and sharedir in GUC, rather than leave these as
compiled-in defaults?

Because Win32 can probe for the location of the binary, it seems it
should check to see if it can find libdir and sharedir own its own and
set those GUC values accordingly as part of initdb.

Basically I am sugesting that initdb set these defaults as GUC
variables, rather than having the backend use compiled-in defaults, and
Win32 can also use the binary location to find them and set the GUC
values.

In other words:
#dynamic_library_path = '$libdir'

could maybe become:
#dynamic_library_path = '/usr/local/pgsql/lib'

and if it doesn't match the default, the comment is removed:
dynamic_library_path = '/usr/local/pgsql/lib'

initdb would make these adjustments.  Same for sharedir.

--  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
 


Re: Fixed directory locations in installs

From
Peter Eisentraut
Date:
Bruce Momjian wrote:
> Also, Win32 installs are going to want to be more directory
> independent than Unix.

Why?

> Because Win32 can probe for the location of the binary, it seems it
> should check to see if it can find libdir and sharedir own its own
> and set those GUC values accordingly as part of initdb.

This is just going to open up the possibility of silently finding the 
wrong files.



Re: Fixed directory locations in installs

From
Bruce Momjian
Date:
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Also, Win32 installs are going to want to be more directory
> > independent than Unix.
> 
> Why?

Because when I install Win32 stuff on my machine via an installer, it
says "Where do you want the files" and puts it in C:\ or C:\Program
Files or whatever I supply.  We need to have that functionality.

> > Because Win32 can probe for the location of the binary, it seems it
> > should check to see if it can find libdir and sharedir own its own
> > and set those GUC values accordingly as part of initdb.
> 
> This is just going to open up the possibility of silently finding the 
> wrong files.

Yes, it does.  We need to check if the directory actually exists.  If
the files we need don't exist in there, we will throw an error anyway,
and they will have to use a flag to specify the location.  Win32 is
going to install everything under one directory anyway, so it should
work fine in most cases.

The only problem case would be where you have an initdb binary that sits
in a directory tree where the ../share and ../lib have files that initdb
needs, but they don't match the initdb version or something, but that
seems like a wacked-out configuration by any measure.

--  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
 


Re: Fixed directory locations in installs

From
Andrew Dunstan
Date:

Peter Eisentraut wrote:

>Bruce Momjian wrote:
>  
>
>>Also, Win32 installs are going to want to be more directory
>>independent than Unix.
>>    
>>
>
>Why?
>

Common practice, for one thing. Windows programs are typically 
relocatable, and Windows admins regard programs that rely on hardcoded 
paths very poorly indeed.

The usual location used by an installer is something like 
%ProgramFiles%/progname or %ProgramFiles%/progname/version - the 
definition of %ProgramFiles% is determined by the machine it is being 
installed on, not by the installer, and certainly can't be set at 
compile time. The machine might not even have a C: drive, for instance.

But this is not only a Windows issue, as Tom reminded us recently. If I 
understood him correctly, there have been calls for relocatable 
installations from other binary packagers.

>
>  
>
>>Because Win32 can probe for the location of the binary, it seems it
>>should check to see if it can find libdir and sharedir own its own
>>and set those GUC values accordingly as part of initdb.
>>    
>>
>
>This is just going to open up the possibility of silently finding the 
>wrong files.
>  
>

Maybe it could be improved by using more version markers?

cheers

andrew



Re: Fixed directory locations in installs

From
Andrew Dunstan
Date:

Bruce Momjian wrote:

>
>In other words:
>
>    #dynamic_library_path = '$libdir'
>
>could maybe become:
>
>    #dynamic_library_path = '/usr/local/pgsql/lib'
>

Not sure I follow - dynamic_library_path is a colon-separated set of 
paths. How will somone using $libdir have that resolved? ISTM we need to 
have another GUC var which sets it, rather than have it compiled in and 
not able to be overridden. It's not really an initdb-time thing either - 
it's an install-time thing - so the installer could add the right path 
to postgresql.conf.sample. Of course, if people move directories around 
after installation they are asking to shoot themselves in the foot, but 
that's true now anyway.


cheers

andrew



Re: Fixed directory locations in installs

From
Tom Lane
Date:
Andrew Dunstan <andrew@dunslane.net> writes:
> Peter Eisentraut wrote:
>> This is just going to open up the possibility of silently finding the 
>> wrong files.

> Maybe it could be improved by using more version markers?

AFAICS the sharedir will already be sufficiently checked by means of
initdb's check on the postgres.bki version marker.  In some sense, the
sharedir used by initdb is the *right* one for an installation by
definition --- I'm not even convinced that we should allow people to
fool with this after the fact.  (However, it's probably not worth the
trouble to develop a non-GUC mechanism to transmit the setting from
initdb to backend.)

We could add a version-marker file to libdir, but it'd not really be a
sufficient check since people might copy their own shlibs in there from
a prior installation without recompiling; and as soon as someone adds
more directories to dynamic_library_path, all bets are off anyway.
We've seen the "wrong version of plpgsql.so" symptom often enough that
I've thought seriously of insisting on a backend-version marker embedded
right into shlibs loaded by the backend.  This'd be easy enough if we
were willing to demand a source code addition in loadable modules, say
a macroBACKEND_VERSION_MARKER
which'd compile to some sort of preinitialized global variable or constant
function returning a version string.  I haven't been able to think of a
way to insert such a marker without source-level cooperation though.
        regards, tom lane


Re: Fixed directory locations in installs

From
Tom Lane
Date:
I wrote:
> AFAICS the sharedir will already be sufficiently checked by means of
> initdb's check on the postgres.bki version marker.  In some sense, the
> sharedir used by initdb is the *right* one for an installation by
> definition --- I'm not even convinced that we should allow people to
> fool with this after the fact.

Actually, looking at the present contents of the sharedir, I'm not even
sure that the backend needs to access it at all.  Most of the files in
there are used only by initdb.  The only thing that seems needed after
initdb is unknown.pltcl, and I'd not have a problem with moving that to
libdir.
        regards, tom lane


Re: Fixed directory locations in installs

From
Bruce Momjian
Date:
Tom Lane wrote:
> I wrote:
> > AFAICS the sharedir will already be sufficiently checked by means of
> > initdb's check on the postgres.bki version marker.  In some sense, the
> > sharedir used by initdb is the *right* one for an installation by
> > definition --- I'm not even convinced that we should allow people to
> > fool with this after the fact.
> 
> Actually, looking at the present contents of the sharedir, I'm not even
> sure that the backend needs to access it at all.  Most of the files in
> there are used only by initdb.  The only thing that seems needed after
> initdb is unknown.pltcl, and I'd not have a problem with moving that to
> libdir.

Are you aware timezone is now in /share, at least in Win32, and maybe on
Unix some day?

--  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
 


Re: Fixed directory locations in installs

From
Bruce Momjian
Date:
Bruce Momjian wrote:
> Tom Lane wrote:
> > I wrote:
> > > AFAICS the sharedir will already be sufficiently checked by means of
> > > initdb's check on the postgres.bki version marker.  In some sense, the
> > > sharedir used by initdb is the *right* one for an installation by
> > > definition --- I'm not even convinced that we should allow people to
> > > fool with this after the fact.
> > 
> > Actually, looking at the present contents of the sharedir, I'm not even
> > sure that the backend needs to access it at all.  Most of the files in
> > there are used only by initdb.  The only thing that seems needed after
> > initdb is unknown.pltcl, and I'd not have a problem with moving that to
> > libdir.
> 
> Are you aware timezone is now in /share, at least in Win32, and maybe on
> Unix some day?

We could move the timezone under /lib if that would make things easier.

--  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
 


Re: Fixed directory locations in installs

From
Peter Eisentraut
Date:
Andrew Dunstan wrote:
> Common practice, for one thing. Windows programs are typically
> relocatable, and Windows admins regard programs that rely on
> hardcoded paths very poorly indeed.

OK, but how can that work in general?  How do other programs handle 
this?  I don't think we should design a solution that goes like "ok, if 
we move that file from share to lib then we could get away with it for 
now".  That will only postpone the potential problems.  There needs to 
be a definite and fixed place where programs can go looking to find the 
files they need.  Maybe it should be stored in that registry thing?



Re: Fixed directory locations in installs

From
"Magnus Hagander"
Date:
>> Common practice, for one thing. Windows programs are typically
>> relocatable, and Windows admins regard programs that rely on
>> hardcoded paths very poorly indeed.
>
>OK, but how can that work in general?  How do other programs handle
>this?  I don't think we should design a solution that goes
>like "ok, if
>we move that file from share to lib then we could get away with it for
>now".  That will only postpone the potential problems.  There needs to
>be a definite and fixed place where programs can go looking to
>find the
>files they need.  Maybe it should be stored in that registry thing?

To make it work more cross-platform, replace "that registry thing" with
"postgresql.conf". It's basically the same thing, except the registry
has a hierarchy model.

And yes, that's how most other programs handle it.


//Magnus


Re: Fixed directory locations in installs

From
Peter Eisentraut
Date:
Magnus Hagander wrote:
> To make it work more cross-platform, replace "that registry thing"
> with "postgresql.conf". It's basically the same thing, except the
> registry has a hierarchy model.

That only works as long as all the files we want to refer to are used by 
the server.  But how will psql find /etc/psqlrc, how will libpq find 
pg_service.conf, how will pg_dumpall find pg_dump, etc.?



Re: Fixed directory locations in installs

From
Andrew Dunstan
Date:

Peter Eisentraut wrote:

>Andrew Dunstan wrote:
>  
>
>>Common practice, for one thing. Windows programs are typically
>>relocatable, and Windows admins regard programs that rely on
>>hardcoded paths very poorly indeed.
>>    
>>
>
>OK, but how can that work in general?  How do other programs handle 
>this?  I don't think we should design a solution that goes like "ok, if 
>we move that file from share to lib then we could get away with it for 
>now".  That will only postpone the potential problems.  There needs to 
>be a definite and fixed place where programs can go looking to find the 
>files they need.  Maybe it should be stored in that registry thing?
>
>
>  
>

Not portable. Also, storing things in the registry is pretty much the 
Windows equivalent of storing things in /etc, an idea which has lately 
been treated with less than universal approval, and suffers from almost 
exactly the same problems. In particular, we need to ensure that a) you 
don't need to be root/Administrator to install, and b) you can reliably 
have multiple installations coexisting.

cheers

andrew



Re: Fixed directory locations in installs

From
Bruce Momjian
Date:
Peter Eisentraut wrote:
> Magnus Hagander wrote:
> > To make it work more cross-platform, replace "that registry thing"
> > with "postgresql.conf". It's basically the same thing, except the
> > registry has a hierarchy model.
> 
> That only works as long as all the files we want to refer to are used by 
> the server.  But how will psql find /etc/psqlrc, how will libpq find 
> pg_service.conf, how will pg_dumpall find pg_dump, etc.?

Actually, postgresql.conf only works once they run initdb (and we have
PGDATA defined).  We still have the open issue of how initdb finds
postgresql.conf.sample unless we embed the file in the initdb binary
(double-yuck).

For pg_dump on Unix, we hopefully have it in our path, but on Win32, we
will not.

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?

--  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
 


Re: Fixed directory locations in installs

From
Andrew Dunstan
Date:

Bruce Momjian wrote:

>Peter Eisentraut wrote:
>  
>
>>Magnus Hagander wrote:
>>    
>>
>>>To make it work more cross-platform, replace "that registry thing"
>>>with "postgresql.conf". It's basically the same thing, except the
>>>registry has a hierarchy model.
>>>      
>>>
>>That only works as long as all the files we want to refer to are used by 
>>the server.  But how will psql find /etc/psqlrc, how will libpq find 
>>pg_service.conf, how will pg_dumpall find pg_dump, etc.?
>>    
>>
>
>Actually, postgresql.conf only works once they run initdb (and we have
>PGDATA defined).  We still have the open issue of how initdb finds
>postgresql.conf.sample unless we embed the file in the initdb binary
>(double-yuck).
>
>For pg_dump on Unix, we hopefully have it in our path, but on Win32, we
>will not.
>
>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.

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

No config files / registry entries should be necessary, AFAICS.

cheers

andrew





Re: Fixed directory locations in installs

From
Peter Eisentraut
Date:
Andrew Dunstan wrote:
> Binaries can find other binaries the way they do now: look in our own
> location, then in the path.

No, we can't look into the path.  We have no information that says that 
anything useful pertaining to our installation is 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

Nothing says that ../share contains anything useful.  Maybe it's 
../share/pgsql, or maybe ../share/postgresql, or maybe 
../share/postgresql-7.4.2 or maybe it's elsewhere altogether because 
you have just moved your installation tree to make room for a new one.  
We can't take guesses like this based on "usual installations".

The only hard facts that we can use are hardcoded/compiled-in locations 
and explicit information passed via command-line arguments or 
environment variables.  None of this seems to be useful for Windows 
installations.  As far as I recall, the Windows installation routines 
only ask you for one installation directory but not all the individual 
ones.  If this is true, then we could hardcode relative paths, but 
maybe I'm mistaken.  Can someone give a couple of full examples of 
typical Windows installation layouts?



Re: Fixed directory locations in installs

From
Andrew Dunstan
Date:

Peter Eisentraut wrote:

>Andrew Dunstan wrote:
>  
>
>>Binaries can find other binaries the way they do now: look in our own
>>location, then in the path.
>>    
>>
>
>No, we can't look into the path.  We have no information that says that 
>anything useful pertaining to our installation is in the path.
>

Well, assuming all the binaries are installed in one location our own 
location should do the trick.

>
>  
>
>>Other files could be found by looking in 1) as per commandline (e.g.
>>-L in initdb) 2) hardcoded location, 3) our-location/../share
>>    
>>
>
>Nothing says that ../share contains anything useful.  Maybe it's 
>../share/pgsql, or maybe ../share/postgresql, or maybe 
>../share/postgresql-7.4.2 or maybe it's elsewhere altogether because 
>you have just moved your installation tree to make room for a new one.  
>We can't take guesses like this based on "usual installations".
>
>The only hard facts that we can use are hardcoded/compiled-in locations 
>and explicit information passed via command-line arguments or 
>environment variables.  None of this seems to be useful for Windows 
>installations.  As far as I recall, the Windows installation routines 
>only ask you for one installation directory but not all the individual 
>ones.  If this is true, then we could hardcode relative paths, but 
>maybe I'm mistaken.  Can someone give a couple of full examples of 
>typical Windows installation layouts?
>
>  
>

The only one I can think is typical is all in one location, e.g. as if 
you had specified --prefix="c:/foo/postgresql"

But there might be more exotic animals out there.

cheers

andrew



Re: Fixed directory locations in installs

From
Claudio Natoli
Date:

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>


Re: Fixed directory locations in installs

From
Peter Eisentraut
Date:
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.



Re: Fixed directory locations in installs

From
Claudio Natoli
Date:

Peter Eisentraut wrote:
> 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.

But we want to resolve the locations at run-time, not build or configure
time. For win32, I'm yet to see why this approach is egregious.

Do you have an alternative solution to propose?

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>


Re: Fixed directory locations in installs

From
Peter Eisentraut
Date:
Claudio Natoli wrote:
> Peter Eisentraut wrote:
> > 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.
>
> But we want to resolve the locations at run-time, not build or
> configure time.

If that is your intention then your original proposal was wrong to begin 
with, because it resolves the locations even before build time.



Re: Fixed directory locations in installs

From
"Magnus Hagander"
Date:
> The only hard facts that we can use are hardcoded/compiled-in
> locations and explicit information passed via command-line
> arguments or environment variables.  None of this seems to be
> useful for Windows installations.  As far as I recall, the
> Windows installation routines only ask you for one
> installation directory but not all the individual ones.  If
> this is true, then we could hardcode relative paths, but
> maybe I'm mistaken.  Can someone give a couple of full
> examples of typical Windows installation layouts?

Not sure if this is exactly what you're looking for, but here's a try.

Microsoft SQL Server 2000:
Base directory: c:\Program Files\Microsoft SQL Server
Server root:    c:\Program Files\Microsoft SQL Server\MSSQL
.EXE & .DLL:    c:\Program Files\Microsoft SQL Server\MSSQL\Binn
.sql used@inst: c:\Program Files\Microsoft SQL Server\MSSQL\Install
Internal .DLLs: c:\Program Files\Microsoft SQL Server\80\Com
Client tools:   c:\Program Files\Microsoft SQL Server\80\Tools
Default datadir:c:\Program Files\Microsoft SQL Server\MSSQL\Data


Not an example of a simple layout, certainly. For something a little
more "consistent", Exchange Server 2000:
Base directory: c:\Program Files\exchsrvr
.EXE/.DLL:        c:\Program Files\exchsrvr\bin
Default Datadir:c:\Program Files\exchsrvr\mdbdata
Language DLLs:  c:\Program Files\exchsrvr\res
Schema @inst:   c:\Program Files\exchsrvr\Schema
Log files:      c:\Program Files\exchsrvr\<servername>.log

As you can see, this one is more clean.

You can typically change the Base directory, as well as the data
directory. The other subdirectories are normally locked relative to the
base directory. Some will let you split out client side files and server
side files into different directories, if both are installed.

//Magnus



Re: Fixed directory locations in installs

From
Claudio Natoli
Date:
Peter Eisentraut wrote:
> Claudio Natoli wrote:
> > Peter Eisentraut wrote:
> > > 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.
> >
> > But we want to resolve the locations at run-time, not build or
> > configure time.
> 
> If that is your intention then your original proposal was 
> wrong to begin with, because it resolves the locations even before build
time.

Huh? I guess it could be seen like that, as the subdirectory component is
fixed. 

But from a win32/installer POV the only dir that matters IMHO is the install
root dir, which certainly is not fixed before build time in the original
proposal. I suspect we are talking at cross-purposes, because that seems
like exactly what you were asking for in the second paragraph here:
http://archives.postgresql.org/pgsql-hackers/2004-05/msg00064.php

Got an alternative run-time/win32-install-time solution to offer?

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>


Re: Fixed directory locations in installs

From
"Andrew Dunstan"
Date:
Claudio Natoli said:
>
>
> Peter Eisentraut wrote:
>> 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.
>
> But we want to resolve the locations at run-time, not build or
> configure time. For win32, I'm yet to see why this approach is
> egregious.
>
> Do you have an alternative solution to propose?
>

I hope we are at cross purposes here, or else Peter's suggestion won't
fly - we need to be able to decouple some of these things from
configure/build time and defer them to installation/runtime. Any other
result will have us attracting curses from on high from the whole Windows
community, and other binary packagers won't get what I understand some
want.

How about if we have a configuration flag --enable-relocation which would
require a fixed layout based on an indeterminate root. This would have the
following effects:

. if prefix did not contain 'postgres' or 'pgsql' then 'postgresql' would
be appended.
. all *dir configure options would be forbidden - they would be based on
the prefix as now, and since it would contain 'postgres' the simple layout
we want would be used.
. binaries would have a DEFINE which would mean they would know they
should look for other binaries and shared files in locations which are
fixed relative to their own location rather than in the hardcoded
locations.

None of this should need a single #ifdef WIN32 :-)

(Would we need to turn off rpath for Unix in such a case? I suspect we
would.)

cheers

andrew






Re: Fixed directory locations in installs

From
Claudio Natoli
Date:
Andrew Dunstan writes:
> How about if we have a configuration flag --enable-relocation which would
> require a fixed layout based on an indeterminate root. This would have the
> following effects:
> 
> . if prefix did not contain 'postgres' or 'pgsql' then 
> 'postgresql' would be appended.
> . all *dir configure options would be forbidden - they would 
> be based on the prefix as now, and since it would contain 'postgres' the 
> simple layout we want would be used.
> . binaries would have a DEFINE which would mean they would know they
> should look for other binaries and shared files in locations which are
> fixed relative to their own location rather than in the hardcoded
> locations.

Looks good to me. Others?

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>


Re: Fixed directory locations in installs

From
Bruce Momjian
Date:
Andrew Dunstan wrote:
> Claudio Natoli said:
> >
> >
> > Peter Eisentraut wrote:
> >> 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.
> >
> > But we want to resolve the locations at run-time, not build or
> > configure time. For win32, I'm yet to see why this approach is
> > egregious.
> >
> > Do you have an alternative solution to propose?
> >
> 
> I hope we are at cross purposes here, or else Peter's suggestion won't
> fly - we need to be able to decouple some of these things from
> configure/build time and defer them to installation/runtime. Any other
> result will have us attracting curses from on high from the whole Windows
> community, and other binary packagers won't get what I understand some
> want.
> 
> How about if we have a configuration flag --enable-relocation which would
> require a fixed layout based on an indeterminate root. This would have the
> following effects:
> 
> . if prefix did not contain 'postgres' or 'pgsql' then 'postgresql' would
> be appended.
> . all *dir configure options would be forbidden - they would be based on
> the prefix as now, and since it would contain 'postgres' the simple layout
> we want would be used.
> . binaries would have a DEFINE which would mean they would know they
> should look for other binaries and shared files in locations which are
> fixed relative to their own location rather than in the hardcoded
> locations.

Rather than turn off configure options, we can easily make this work for
arbitary configure flags.

Everything on Win32 drives off of the directory of the binary, which we
can probe for at runtime.

If they use the configure defaults, /lib is ../lib relative to /bin.  If
they specify:
bin    /usr/local/pgsql/binlib    /usr/local/lib/pgsql

then lib is ../../lib/pgsql relative to bin.

It is easy to write a C function that will give us the relative path
from bin to any of the compiled in locations like /lib or /share, and we
can use that instead of an abolute path.

Not sure how we can do this for Unix except perhaps probe PATH.

--  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
 


Re: Fixed directory locations in installs

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Not sure how we can do this for Unix except perhaps probe PATH.

Huh?  We have always determined the full path of the executable ---
see FindExec().

I guess what you are saying is we should have a configure-time option to
address configured directories via relative paths from the executable's
directory, rather than absolute paths?  Seems reasonable ...
        regards, tom lane


Re: Fixed directory locations in installs

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Not sure how we can do this for Unix except perhaps probe PATH.
> 
> Huh?  We have always determined the full path of the executable ---
> see FindExec().


Oh, OK.  I forgot that.

> I guess what you are saying is we should have a configure-time option to
> address configured directories via relative paths from the executable's
> directory, rather than absolute paths?  Seems reasonable ...

Yep.  In fact, why would we not use that by default?

--  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
 


Re: Fixed directory locations in installs

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> I guess what you are saying is we should have a configure-time option to
>> address configured directories via relative paths from the executable's
>> directory, rather than absolute paths?  Seems reasonable ...

> Yep.  In fact, why would we not use that by default?

Because it'll be slower.  Instead of/usr/local/pgsql/lib
we'd be using something like/usr/local/pgsql/bin/../lib
which is not too bad here but would get worse if the directories are not
so close.

But perhaps we can arrange for the path to be simplified down to an
absolute form when it's constructed at backend startup?  You'd need a
routine anyway to combine the bindir path (determined by FindExec) with
the relative path provided by configure, so maybe this routine could be
smart about leading ../ in the configure path.

We'd also need to give some thought to pg_config output.  I think I
would like to be able to see the relative path computed by configure
as well as the effective actual path ... maybe a switch to specify which
way to print it?
        regards, tom lane


Re: Fixed directory locations in installs

From
Peter Eisentraut
Date:
Tom Lane wrote:
> We'd also need to give some thought to pg_config output.  I think I
> would like to be able to see the relative path computed by configure
> as well as the effective actual path ... maybe a switch to specify
> which way to print it?

What use could printing the relative path possibly have?  It would only 
be relative to the location of pg_config, which is of no interest to 
the user of the printed information.  Let's not make this more 
complicated than it needs to be.



Re: Fixed directory locations in installs

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> We'd also need to give some thought to pg_config output.  I think I
>> would like to be able to see the relative path computed by configure
>> as well as the effective actual path ... maybe a switch to specify
>> which way to print it?

> What use could printing the relative path possibly have?

Debugging.  If I can't see it, I *know* I'm going to wish I could.
        regards, tom lane


Re: Fixed directory locations in installs

From
Peter Eisentraut
Date:
Tom Lane wrote:
> > What use could printing the relative path possibly have?
>
> Debugging.  If I can't see it, I *know* I'm going to wish I could.

Well, you can just look inside, it's not that big.  Supporting extra 
options might make the script twice as big and thus make it harder to 
just look at the whole thing.



Re: Fixed directory locations in installs

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> I guess what you are saying is we should have a configure-time option to
> >> address configured directories via relative paths from the executable's
> >> directory, rather than absolute paths?  Seems reasonable ...
> 
> > Yep.  In fact, why would we not use that by default?
> 
> Because it'll be slower.  Instead of
>     /usr/local/pgsql/lib
> we'd be using something like
>     /usr/local/pgsql/bin/../lib
> which is not too bad here but would get worse if the directories are not
> so close.
> 
> But perhaps we can arrange for the path to be simplified down to an
> absolute form when it's constructed at backend startup?  You'd need a
> routine anyway to combine the bindir path (determined by FindExec) with
> the relative path provided by configure, so maybe this routine could be
> smart about leading ../ in the configure path.
> 
> We'd also need to give some thought to pg_config output.  I think I
> would like to be able to see the relative path computed by configure
> as well as the effective actual path ... maybe a switch to specify which
> way to print it?

Does this pg_config addition need to be done?

--  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
 


Re: Fixed directory locations in installs

From
Bruce Momjian
Date:
Peter Eisentraut wrote:
> Tom Lane wrote:
> > > What use could printing the relative path possibly have?
> >
> > Debugging.  If I can't see it, I *know* I'm going to wish I could.
> 
> Well, you can just look inside, it's not that big.  Supporting extra 
> options might make the script twice as big and thus make it harder to 
> just look at the whole thing.

OK, this is a followup from Peter on the pg_config issue.  We only do a
relative path if they used the defaults and put it all under a single
directory so there is probably little need for a pg_config addition.

--  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