[FGS] Status / httpd / etc

[Frank Warmerdam]

Daniel Morissette wrote:
> 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.

Daniel,

Certainly, I want it to extend beyond GDAL and OpenEV.  Basically any
GIS/RemoteSensing type application that folks are interested in
supporting should be a candidate.  The big caveat being that only
packages for which someone is interested enough to do the packaging would
make it in.

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

Note, the base includes python interfaces for packages in the base, but
it doesn't include python itself.  The python interfaces add relatively
little to the size but ensure that if the user has a compatible python
on their system or downloads the FGS python they are away to the races.

I have tried to avoid bundling huge things like Python itself into the
base.

 > 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?

I think GRASS is too big to go into the base, and if a package depends
on GRASS in a major way then that package would need to depend on GRASS.

For something like GDAL support for GRASS files, I would anticipate
including libgrass in the base - or - using the the new GRASS 5.7 based
GDAL driver put delivering it as a demand-loaded driver so that GDAL
can work fine without GDAL.

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

An interesting example.

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

I must admit that at this point I am inclined to just go back to release
OpenEV_FW linux releases and leave broader packaging to others.  I don't
want to  be the trouble maker that just makes life difficult for everyone.
I think that the goals of most folks interested in FGS are broader than
mine and that is causing some problems.  For instance, for simplicity and
consistency I would prefer we only build FGS on maxine for linux.

For now, I'll let you folks continue on and once things settle down a bit
perhaps I can help flesh out the GDAL package to include as many options
as are practical.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent