[osgeo4w-dev] [Board] Writing up OSGeo priorities

Tamas Szekeres szekerest at gmail.com
Tue Mar 5 13:01:09 PST 2013

2013/3/5 Frank Warmerdam <warmerdam at pobox.com>

> 1. Packages coming from various sources being made by hand in a
>> non-regular fashion may cause the overall system fragile, incompatibilities
>> between versions dependencies may likely happen.
> This is certainly true, but I also think it has been a substantial
> contributor to ability to get contributions from lots of projects which
> often have fairly ideosyncratic build configurations.

Hi Frank,

For me it's difficult to imagine a build process which cannot be automated.
Automation may require some extra work, but we save much more efforts
regarding to the subsequent builds. Each project may however require one
time actions to install the prerequisites into the right places. This may
indeed require contribution especially when upgrading those versions.

> The overall build process is out of the control, it's quite difficult to
>> reproduce at least the same build without requiring the package providers
>> to participate. We are reusing  the same dependencies among various
>> projects which is not necessarily be the only way to follow.
>> In my opinion if we continue to go with this multi-package concept, we
>> could probably make it more reliable if we don't let the users to create
>> their packages by hand. We should provide a build environment (a dedicated
>> server) to provide the builds and the users should just author their build
>> scripts which would check out the sources and compile it regularly or the
>> build would be triggered by someone who is authorized to do it.
> I think this would substantially narrow the set of projects that end up
> getting incorporated though it would certainly be likely that they would be
> less fragile.
Not sure why. I don't think if the projects are not interested in being
part of the build process. I also think it's a pressure for the
contributors to regularly upgrade their binaries in the osgeo4w repository.

> 2. The current cygwin based installer is not necessarily be convenient for
>> most Windows users.  I consider on Windows the users would rather require
>> pre-bundled msi installers which would make things up and running instead
>> of dealing versions and sub-package dependencies in mind. Users would not
>> want to be in familiar with which version of zlib or curl is installed for
>> MapServer or QGIS to run correctly. Installers may however contain feature
>> selection options and further customizations according to the requirement
>> of the project specifically.
> Hmm, to me this flies in the face of what I had hoped to accomplish with
> OSGeo4W.  I imagined it much like linux distributions such as Debian where
> only one copy of dependencies would exist on the system  except in very
> rare circumstances.  I think ou are describing a way of building
> essentially standalone installers for things like QGIS or MapServer that
> would be distinct and duplicating things like GDAL.  Is that right?  That
> could certainly have some value but it is quite different than what I
> dreamed of.
> For instance I dreamed of a world where if one managed to install support
> for a GDAL plugin it would become available to all GDAL based packages on
> the system (well in the OSGeo4W world at least).
Not sure this is a concept that should be phased out. But this scheme would
apply for the centralized build process I've mentioned. It is very
difficult to provide consistent builds if the parts are produced in
different environments and different authors.

We could also run the build scripts of the project installers as part of
the build process. Installers would rely of the previously compiled files
from OSGeo4w or it would also be possible to recompile different versions
of certain dependencies if required.

> For example QGIS and MapServer may have similar dependencies (like GDAL)
>> but it not necessarily be the same version. Project may be installed into
>> different target directories with different versions of the same
>> dependencies side by side. This would let the projects provide more
>> consistent builds without being affected by versions of external
>> dependencies. Some of the projects may require further actions which could
>> also be included in the installers as custom actions. For example we may
>> probably install MapServer  with IIS registration, or bundled with a Web
>> server like Apache or both.
>> We could however aim to use the same version of GDAL between multiple
>> projects, but it would be essential to build the complete system in a
>> centralized fashion and making sure about the correct build order according
>> to the project hierarchies. Packages from a single project should also be
>> build in a single process. I doubt it is a good solution for example to
>> build GDAL core and the plugins or the bindings different times.
>> Since #1 is mostly about a build concept we could probably start with
>> authoring the buildsystem and then build several installer on the top and
>> the cygwin or the msi based packages could exist side by side.
> Despite my hesitancy on the above points, I am working with Alex Mandel to
> setup a windows build VM that I hope can be reasonably widely sharable and
> that could be used to reproduce some of the major dependencies like GDAL in
> a reproducible way.
That seems to be promising indeed.

> My original point to the board was that I hesitate to fire money at
> OSGeo4W as long as we are having trouble building a vision of how to
> proceed with it.  Certainly my view of Debian-like packaging has not got
> universal acclaim, nor has the current approach of haphazard hand building
> of packages always worked out well.
I think not all of the (Windows) users are involved to see the details,
just download the project installer and get it up and running. It would
also be a requirement to get automated builds for the latest fixes, because
it is not so easy to compile the binaries from sources in most cases.

Best regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/osgeo4w-dev/attachments/20130305/e5d8de1e/attachment.html>

More information about the osgeo4w-dev mailing list