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 _______________________________________________ osgeo4w-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/osgeo4w-dev
