Re: Relocatable installs

On Sun, 9 May 2004, Bruce Momjian wrote:

> Shachar Shemesh wrote:
> > Bruce Momjian wrote:
> >
> > >Comments?
> > >
> > >
> > What's wrong with the way it's done by everybody else?
> >
> > Have hardcoded paths (determined at configure time), and allow override
> > using a config file. Have a command line option for saying where the
> > config file should be.
>
> Where do we put the config file so it can be found? We can't assume
> root privilege to write into /etc.

The default location for the config file would be compiled into the
binary based on whatever settings were given when it was built.

If someone wants to use a different location after it is compiled,
they have to specify the config file path on the command line. For
starting up the database, that isn't a big deal because you normally
should be using some wrapper script anyway.

This is how the vast majority of other programs do it on unix.
Apache, mysql, BIND, the list goes on.

The downside to this is that it isn't as friendly for various
command line tools that people run, since they then have to specify
the path on the command line. One option to deal with this is to
allow compiling in a default path that is optionally relative to
the directory the binary is in, eg. "../foo/bar" would be relative
to where the binary is, while "/foo/bar" would be absolute. Then
there is a choice at build time; it could default to paths relative
to the binary and allow overriding that if the user compiling it wants
something different.

One key thing that this gives that the other proposals don't is the
ability to have a single, static tree of program files and run multiple
different instances of the database off them, each having their own
unique configuration and data trees. This also makes it easier to move
back and forth between different minor versions for testing or QA
just by tweaking a startup script to point to a different binary
tree, without having to copy data, config, or binaries around. In
this scenario, the above downside can be worked around by just
creating simple wrapper scripts.

We use this type of setup with products such as Apache to manage
having code for different projects or different versions of products
running out of different development or QA or production trees that
uses different versions of Apache, to ensure we are developing and
testing against the same version that will be in production, and
that we can manage upgrades on a project by project basis.

So, for example you could have:

/site/httpd/httpd-2.0.45
/site/httpd/httpd-2.0.45-2
/site/httpd/httpd-2.0.48

containing static copies of the binaries and libraries that are never
ever modified. All the config files and data live in specific projects,
then we just configure that project to use a specific version of Apache.
Multiple versions can live on a machine and each project can pick which
one it wants to use and easily upgrade to new ones, without having a
whole bunch of copies of the binaries.

While this is slightly less useful for postgresql, both because fewer
people want to be able to concurrenetly run multiple different instances
on the same box for testing purposes and because the database generally
has to be modified to work between non-minor version changes, it is
still something that is very useful in some environments and I would
love to have.

>
> > For Windows, replace config file with "Registry". That is usually
> > hardcoded for (depending on whether you want it changeable per-user)
> > HKEY_LOCAL_MACHINE\Software\<company name>\<product name> (replace HKLM
> > with HKEY_LOCAL_USER if you want per-user config).
>
> Doesn't registry require admin privilege on the Windows box?

Not if it is in the per user part as Shachar suggested.

If it is done this way, however, it should be possible to override
the registry via command line flags to allow multiple installations
on the same box in different places.