[osgeo4w-dev] mapserver/mapscript packages for osgeo4w

[Jürgen E. Fischer]

Hi Tamas,

On Wed, 05. Feb 2014 at 09:04:41 +0100, Tamas Szekeres wrote:
> In my preference the same directory structure for osgeo4w and osgeo4w_64
> would be a reasonable choice.

Of course.

> Currently we have a "mapserver" directory which can be promoted to host the
> release versions. But I'm now about to provide the latest builds for the
> master and the stable branches which would apply for 2 different directories.
> I could also provide builds for the release version, but it will more likely
> break something for the existing stuff so it should be just a later phase
> when we should gather experiences with that.

As said, that will probably not matter.  I'd expect that the current mapserver
stuff only partly works - so anything we do can only make it better.

> My biggest concern about this concept (as I've already raised that at the
> conference) is that we cannot make sure that providing a new package will not
> break the upper level packages which depend on the package added. And the
> package author may not have experiences to compile all the upper level
> packages to make sure about all aspects. We should instead automate the whole
> build process in the osgeo4w server which would make it easier to recompile
> the whole bundle.

The 64bit build at least has build recipes (the -src packages, that don't
actually have source) for everything, that is actually build.  There are also
some packages that are repackaged binaries from elsewhere - which don't have
recipes.  Build dependencies are not addressed yet in the build recipes, so
there's currently no way to know what to needs to be rebuild - the source
itself is also not included.

I never had access to the server Alex setup on his campus, I also don't know if
it's still there.   And frankly I don't see the big issue - we don't have a
load of maintainers to coordinate - and most packages have quite a livetime,
because they are only dependant packages, that won't get upgraded without an
actual need.

Having a build server would be a plus and help with more up-to-date packages,
but it also means a lot of initial work.  It's optional, but still requires
to redo stuff that's already there.  But if I had a machine and the time I
would probably jump on it. ;)

And given that I don't recall that we actually had any problem with
incompabilities yet.  A package maintainer should know what interfaces his
packages have and when dependant package need to be rebuild and in that case
coordinate with maintainers of those packages.

> The current directory structure is not quite right regarding to the package
> versions.

Mostly the mapserver part - I'd vote for removing all of that - and have one
stable mapserver package (set) and if necessary a nightly build of trunk - just
like qgis and qgis-dev.

To me the variety of mapserver packages is just a matter of lack of
maintainance and oversight.  It appears to me that a some point someone ported
MS4W to OSGeo4W once and then stopped careing about it.  And later others
stepped up, but added newer versions as separate packages instead of updating
the old ones and only added the bindings that they needed - thereby avoiding
any responsibility to care about the upgrade process.

A newer version should replace the previous version, if necessary 'requires'
other dependencies, so that it can be updated smoothly.  I don't see a need for
multiple versions of the same package - except of course for a stable and
nightly builds (and preferably both can live in same install).


Jürgen

-- 
Jürgen E. Fischer         norBIT GmbH               Tel. +49-4931-918175-31
Dipl.-Inf. (FH)           Rheinstraße 13            Fax. +49-4931-918175-50
Software Engineer         D-26506 Norden               http://www.norbit.de

-- 
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502