[osgeo4w-dev] Questions

[Frank Warmerdam]

Ari Jolma wrote:
> Not much traffic so far on this list. Maybe I'll post a few questions:

Ari,

I held off for a while for folks to join, and then got busy on other
stuff.

> - What's the current idea of a product? A big bundle of everything or a 
> kind of meta installer, which goes through a series of questions with 
> the user and then goes out to internet to download and install the 
> requested packages?

I believe the intention is you would download an installer ".exe" which
would present you with a set of packages you can select, and it would
download pre-built packages from an OSGeo distribution point based on
your selection and install them.

This approach is quite different than the existing FWTools or MS4W
installer (I think) which include all components in the .exe even if
you only choose to install some.

It is not clear whether the download .exe would include as part of it
some core of packages or not.  I suspect it would have to if we are
going to depend on a PHP runtime as our scripting language for stuff
to hard to do in the NSIS installer language.

FGS, for instance, has a way of preparing a bundled install which
includes a large set of packages in the single download, but you can
still go back and use the fgs-install script to pull down additional
packages.  So we might want to do something similar, including a core
of widely useful libraries and components in the base installer, and
just fetching other stuff depending on user selections.

Note, when I talk about going back to fetch packages, I am not expecting
these to be generic binaries for windows, but rather a package prepared
to fit smoothly into the OSGeo4W scheme.

> - I'm not very knowledgeable about executables in Windows but I know for 
> example that I can't mix Activestate Perl (compiled with VC I believe) 
> with Perl modules that are compiled with (or in?) MinGW. However, I can 
> use for example binary distributions of PostGIS DLLs with GDAL that I've 
> compiled with MSYS. (I'm not sure what I'm asking here, except that I'd 
> be happy to be able to rely on an existing gdal.dll for example)

Yes, we will have to make some decisions on things like this, and develop
some expertise on what works with what.  For instance, it may be hard for
to call into a C++ API build with a different compiler but C APIs are
generally ok to do this.

For FWTools I took the approach that everything I control is built with
VC7.1 though a few low level DLLs come from other sources and were built
with other tools.  I don't think we can be quite so restrictive with
OSGeo4W, but some technologies will imply certain choices.  For instance,
I think the "standard" python 2.5 binaries are built with VC8 and Python
extensions for it must be compiled with VC8 too or they won't work.

Part of our "job" in the coming months is to hammer out decisions on
these choices (script language versions, compilers, etc).

I anticipate (though this is certainly not set in stone) that we would
be trying to produce one "generation" of the OSGeo4W installer roughly
every year.  And that when we go to a new generation is when we might
change what versions of python/perl/php we use, and change decisions
on compiler versions.

> - Are we aiming at / supporting users, developers, or hackers? At least 
> the Geoinformatica stack is a bit different for each of these (users 
> need only the GUI app, developers want to write Perl programs, hackers 
> want to install new pure-Perl modules, über-hackers want to compile, 
> install and link in new things).

My opinion is that the *primary* goal is to support end users,
including end users new to the open source geospatial world.  I *hope*
we can include stub libraries, and include files for packages so that
the OSGeo4W install of base packages can also be useful to developers.
In fact, I think this will be helpful for people trying to build
additional packages for OSGeo4W.

> - When will the questions on the wiki page be answered? I mean is 
> somebody going to write a policy document for example?

Good question. Hopefully we can discuss the issues here.  To some
extent Jeff will decide (and hopefully write up) some things as he
works on the initial core.  In the interest of making progress instead
of getting caught in the "talk shop" phase, I would suggest we let
Jeff do as he needs to do to get an initial core going.

It may be that the first generation (OSGeo4W 2008?) is done one way,
and we learn from that and takes a more democratic/deliberative approach
for OSGeo4W 2009.

> - I've taken the policy that I don't really install the software in 
> Windows, I write a start-up script (using bash as dos batch files suck), 
> which sets up the paths and environment variables etc. Many FOSS seem to 
> work that way and it's a good thing because I don't need to bother our 
> university's Windows-admins to install software. This however does not 
> work for software like PostgreSQL which needs to be installed as a service.

I have certainly taken the same approach with FWTools, and in the past
essentially the same approach was taken with MS4W.  Try not to dump stuff
into C:\windows\system32 and avoid too much registry fiddling, etc.

Jeff has good experience with handling the Apache service.

I could imagine OSGeo4W having an "OSGeo4W Shell" much like the FWTools
Shell as an icon on the desktop that will start up initialized with the
appropriate commandline environment.

But there are downsides to deferring all environment variable setting to
wrapper scripts.

One problem I have had in the past when I don't install stuff into
C:\windows\system32 is that if there are conflicting DLLs already
installed there, they will get used in preference to my own.  To
some extent I have worked around this by adding an _fw postfix to the
DLL names.  But for some core DLLs (zlib, sshlea) or propritetary ones
(oci, mrsid, etc) this isn't possible.  A common failure of FWTools is
when folks have an old mrsid DLL sitting around.  I'd love someone more
knowledgable than me to explain how to avoid this problem.

Or, perhaps, we bite the bullet and figure out how to properly install
at least some "base" DLLs properly in C:\windows\system32 if they are
newer than the existing versions.

Thanks for getting discussions going!

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org