<br>Tamas, <div><br></div><div>I've removed the board since we are getting into project details not of broad interest. </div><div><br></div><div><br><div class="gmail_quote">On Sun, Mar 3, 2013 at 2:26 AM, Tamas Szekeres <span dir="ltr"><<a href="mailto:szekerest@gmail.com" target="_blank">szekerest@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi All,<div><br></div><div>With regards to osgeo4w I think we might consider various things to make the approach more reliable. Not sure I have a strong opinion about the exact direction, but at least the followings should be reconsidered.</div>

<div><br></div><div>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. </div></blockquote>
<div><br></div><div>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.</div><div>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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.</div>

<div>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.</div>
</blockquote><div><br></div><div>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.</div><div><br></div><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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. </div>
</blockquote><div><br></div><div>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. </div>
<div><br></div><div>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). </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>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. </div>

<div>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.</div>

<div><br></div><div>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.</div>
</blockquote><div><br></div><div>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. </div>
<div><br></div><div>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.</div>
<div><br></div><div>Best regards,</div><div>Frank</div><div>-- </div></div>---------------------------------------+--------------------------------------<br>I set the clouds in motion - turn up   | Frank Warmerdam, <a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a><br>
light and sound - activate the windows | <a href="http://pobox.com/~warmerdam" target="_blank">http://pobox.com/~warmerdam</a><br>and watch the world go round - Rush    | Geospatial Software Developer<br>
</div>