[gdal-dev] Re: [mapserver-dev] Design/Re-Design consideration

[Stephen Woodbridge]

Frank Warmerdam wrote:
> Stephen Woodbridge wrote:
>> Hi all,
>>
>> I really like gdal and ogr. I can't say I use them all the time, but 
>> they work and do the job when I need them and I would be lost without 
>> them on some jobs. So Thanks and keep up the good work.
>>
>> I want to toss out an idea that I think would make gdal/ogr better. 
>> This comes from my frustration with the fact that as more formats are 
>> supported, the more system library dependencies that are required to 
>> install it. I was horrified when I went to build mapserver with wfs 
>> support and I only use shapefiles on postgis layers that I had to 
>> install gdal and that pulled in some 20-30 other system packages!!!!
>>
>> This is insane from my perspective. I don't need any of those packages 
>> for the work I'm doing, maybe mapserver should not require gdal for 
>> wfs, but I'm sure there is a good reason for that choice.
> 
> Stephen,
> 
> Note, that you can build a minimalist GDAL if you want. I do it all the
> time to keep size and complexity down.
> 
> Also, GDAL already supports runtime loadable plugins for formats, so this
> can be used in packaging systems to reduce the number of dependencies of
> the core libgdal.  This plugin mechanism is often used for stuff like
> SDE, Oracle, MrSID and ECW dependencies.  It could be applied more widely.
> 
> PS. rather than a config.ini, we normally just determine which plugins
> to load based on which ones are in the gdalplugins directory.
> 
> Best regards,

OK, cool! then it sounds like the only thing needed is better education 
of the package builders. Fedora packages pulled in a huge number of 
packages, and Debian was a little better IIRC but still a lot.

I can build from source and often do on my own systems because I want 
more recent software for testing or to work with, but deployment across 
a bunch of production servers really needs to be done with binary 
packages. Ideally I do not want to have to learn 4-6 different package 
build environments and tools sets. ;)

I hope some of the package builders are on this list and are listening.

Thank you for the feedback,
   -Steve