[FGS] Status / httpd / etc

[Daniel Morissette]

Frank Warmerdam wrote:
> 
> On another point, I don't like seperating things into a bunch of 
> subpackages
> just for find grained control.  You have implemented a bunch of -lib
> packages.    I presume there might also be -bin packages (with actual
> executables) and possibly -dev packages with include files and other dev
> related stuff. Many packages (such as GDAL) are not especially easy to
> split apart properly this way, and generally everything except executables
> build against shared libraries will be small, and -dev include files are
> also small. I just don't feel this degree of fine grainedness is worth
> the trouble.
> 

I agree that too much separation is not a good thing, but a fat base 
package doesn't seem to be viable either, so we need to find something 
in-between. Of course, what we do depends on whether you want this suite 
to be useful to the GIS community in general, or just to the 
Python/GDAL/OpenEv family of products.

If you add to the base everything that is shared by at least two FGS 
applications, then your base will just keep growing in size and contain 
a bunch of stuff that most people don't need. For instance, you included 
Python in the base because you use it with GDAL and OpenEV. In our case 
we use PHP with MapServer, and others use Perl, so should we add PHP and 
Perl to the base? If there are two apps that can make use of some GRASS 
services then do we include GRASS in the basse package? Where do we stop?

What if there is a change of API in PROJ v5 (hypotetical example) that 
makes it so that we need to carry two copies of PROJ in the base package 
because some apps require PROJ5, and others require PROJ4. We can deal 
with that situation easily with the dependency system and the small 
runtime (-lib) package that contains only the libproj.so.x.y.z, but we 
would be stuck if we went with the fat-base approach: we cannot include 
copies of both set of headers and conflicting libproj.so (required only 
for development) in the same base package. That's where the -dev vs -lib 
package separation becomes useful.

I'm not a huge fan of the dependency system and of the fine-grained 
packages either, but it seems that it's the only viable option if the 
objective of FGS is to be usable for any open source GIS package in the 
long run. Of course if that's not the objective then we'll stop bugging 
everyone and we'll maintain our own suite... but hopefully we can avoid 
that.

Daniel
-- 
------------------------------------------------------------
  Daniel Morissette               dmorissette at dmsolutions.ca
  DM Solutions Group              http://www.dmsolutions.ca/
------------------------------------------------------------