Thread: Binary installer
Claudio Natoli wrote: > > Clearly we will need an installer for a binary distribution. The nullsoft installer is quite nice. Not sure about Microsoft .msi packaging...I'm sure that's pretty easy to work with, too. The installer should besides unzip, offer to run a few batch files (initdb, etc), set up the environment, and offer set up the postmaster as a service. A good windows program has no internal dependencies on the registry. Postgres is already set up to use the environment which is a more flexible setup than the registry for servers. Merlin p.s. Is there any way to keep mingw/msys from spamming console windows when compiling? It's very irritating :(.
Gotta disagree with you there.. a good Windows app won't use the
environment at all. Take a look at the environment of a typical Windows
server - the various services don't have any environment variables
related to them, it's all in the registry.
Writing something into HKEY_LOCAL_MACHINE\Software\PostgreSQL that says
where Postgres is installed would be reasonable.. at startup the Win32
code could simply read that variable from the registry and set it into
the environment so the rest of postgres can depend on it being in the
environment.
- Steve
-----Original Message-----
From: Merlin Moncure [mailto:merlin.moncure@rcsonline.com]
Sent: January 23, 2004 9:12 AM
To: Claudio Natoli
Cc: pgsql-hackers-win32
Subject: [pgsql-hackers-win32] Binary installer
Claudio Natoli wrote:
> > Clearly we will need an installer for a binary distribution.
The nullsoft installer is quite nice. Not sure about Microsoft .msi
packaging...I'm sure that's pretty easy to work with, too. The
installer should besides unzip, offer to run a few batch files (initdb,
etc), set up the environment, and offer set up the postmaster as a
service.
A good windows program has no internal dependencies on the registry.
Postgres is already set up to use the environment which is a more
flexible setup than the registry for servers.
Merlin
p.s.
Is there any way to keep mingw/msys from spamming console windows when
compiling? It's very irritating :(.
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
> Gotta disagree with you there.. a good Windows app won't use > the environment at all. Take a look at the environment of a > typical Windows server - the various services don't have any > environment variables related to them, it's all in the registry. Agreed on that. There is also another thing to consider there - it can be a lot of work influencing the environment for a service, unless you start the service with a BAT file (with a wrapper around). And a wrapper around a wrapper around the postmaster doesn't seem so good :-) This is all because the environment is per-user. While there is also a per-machine environment, you really shouldn't put service config in there. And modifying the environment for a *different* requires logging in as that user. The registry is the way to do it on Win32 today (but large data amounts should of course be in a file referenced from the registry). .Net aims to replace it with XML config files, but the registry is still extensively used there. > Writing something into HKEY_LOCAL_MACHINE\Software\PostgreSQL > that says where Postgres is installed would be reasonable.. > at startup the Win32 code could simply read that variable > from the registry and set it into the environment so the rest > of postgres can depend on it being in the environment. Considering the environment is really nice when you run it from the commandline, it should probably use the environment variable *if set*. But *if not*, it should load it from the registry. Also, I'd much rather see HKLM\System\CurrentControlSet\Services\<pgservice>. That way, you can have multiple services installed on the same machine without them affecting each other. You will also automatically get the "protection" of the "Last Known Good Configuration" boot, which will roll back the CurrentControlSet subtree. //Magnus
Steve Tibbett said: > Gotta disagree with you there.. a good Windows app won't use the > environment at all. Take a look at the environment of a typical > Windows server - the various services don't have any environment > variables related to them, it's all in the registry. I agree. Environment means you can't readily set PostgreSQL to run under a different user account because the environment is user specific. > Writing something into HKEY_LOCAL_MACHINE\Software\PostgreSQL that > says where Postgres is installed would be reasonable.. at startup > the Win32 code could simply read that variable from the registry and > set it into the environment so the rest of postgres can depend on it > being in the environment. I am not particular font of the registry either, gets messy quickly when you want to run different instances and setting permissions in the registry is no fun either (IMHO). Why not instead of looking in the registry for the location pass it over the command line? Then load from there and set up the user-specific environment. Jochem
>I am not particular font of the registry either, gets messy >quickly when you want to run different instances and setting >permissions in the registry is no fun either (IMHO). Saying you're not fond of the registry on Win32 is like saying you're not fond of /etc on Unix :) Like it or not, the registry is where Windows apps store their configuration. Another way, to avoid the issue altogether, is infer the install directory from the EXE name (ie, do a GetModuleFileName() to find the full path to the currently executing code, strip off the filename and go up a directory.. something like that). - Steve
Le Fri, Jan 23, 2004, Ã 03:37:48PM +0100, Jochem van Dieten a écrit:
> Steve Tibbett said:
> > Gotta disagree with you there.. a good Windows app won't use the
> > environment at all. Take a look at the environment of a typical
> > Windows server - the various services don't have any environment
> > variables related to them, it's all in the registry.
>
> I agree. Environment means you can't readily set PostgreSQL to run
> under a different user account because the environment is user
> specific.
Not true. There's a per-user section of environment, and a system-wide
section. From the program's point of view, both are merged.
> > Writing something into HKEY_LOCAL_MACHINE\Software\PostgreSQL that
> > says where Postgres is installed would be reasonable.. at startup
> > the Win32 code could simply read that variable from the registry and
> > set it into the environment so the rest of postgres can depend on it
> > being in the environment.
>
> I am not particular font of the registry either, gets messy quickly
> when you want to run different instances and setting permissions in
> the registry is no fun either (IMHO).
>
> Why not instead of looking in the registry for the location pass it
> over the command line? Then load from there and set up the
> user-specific environment.
You mean, -D ?
-- Cyrille
--
Le Fri, Jan 23, 2004, Ã 09:11:40AM -0500, Merlin Moncure a écrit:
> Claudio Natoli wrote:
> > > Clearly we will need an installer for a binary distribution.
>
> The nullsoft installer is quite nice. Not sure about Microsoft .msi
> packaging...I'm sure that's pretty easy to work with, too. The
> installer should besides unzip, offer to run a few batch files (initdb,
> etc), set up the environment, and offer set up the postmaster as a
> service.
From what I know, NSIS is a bit difficult to work with if you want to go
much beyond unpacking a bunch of files and setting stuff in the
registry (which it does nicely and in a reversible way). Specifically,
there is little support for registering a service and tweaking
permissions.
But the killer is that you can't turn an NSIS install into an MSI merge
module.
OTOH, the bare MSI tools aren't renowned for ease of use, and stuff like
InstallShield or Wise are neither Free nor free. For what it's worth,
Python uses Wise.
-- Cyrille
--