[FGS] Source Cache, CVS access

[Frank Warmerdam]

Daniel Morissette wrote:
> Have you looked for the missing packages in 
> http://dl.maptools.org/dl/fgs/fgs-dev/fgs-cache/

Daniel,

Ah, that does the trick.

> If the libs you're missing are freely redistributable and are not there 
> then please let me know which ones they are and I'll add them. It's very 
> possible that this area is not up to date.

I have updated the libungif, and libpng packages to fetch from the
fgs-dev/fgs-cache since fetches from sourceforge result in pulling
back some html and the build process breaks down.

I have also updated the proj package to use a newer datum shift
file package since the old one has moved, and is less complete.

To build libjpeg on my 64bit linux system I found I had to do some
hackery since the ancient libtool in jpeg6b does not recognise x86_64.
But I don't judge this to be suitable to commit.  I am pursuing getting
a libjpeg 6.1.0alpha release produced by the libjpeg team (of which
I am a not very helpful member) and when that occurs I'll update things
to point to it.

>> Is FGS "current" 0.2 or 0.3? 
> 
> 'current' in the download site is a symlink to 0.2
> 
>> When might FGS be ready to start a "next
>> version" with updated versions of things like GDAL, etc. 
> 
> I think what's currently in CVS could be called the dev version for 0.3. 
> It already contains updates for several packages. For instance GDAL may 
> not be at 1.4.2 yet (too recent) but it's been updated to work from SVN 
> recently for instance.

Assuming I can keep things working properly, may I update FGS to
more modern proj, gdal, and libgeotiff packages?

I'd also like to factor some gdal dependencies out into plugins.
For instance postgres, and libecw.  I'm also interested in preparing
gdal-python bindings support which seems practical since FGS already
includes python.

Any advice on building add-on packages like gdal-python or gdal-ecw?
I dont' quite understand why I need to use "gdal-base" as the name of
the gdal package when I do "fgsdev custom_build_list create" and I
wonder how that might relate to gdal plugin packages.

I guess I should try to use the mapserver python mapscript package
as a guide?

> Reading between the lines of your email I can feel the frustration that 
> I had when I first started trying to use it. Then we all seem to do the 
> same thing: we fix a few things as we start using it and never come back 
> to polish it, so the next person trying to use it still has to suffer 
> some of our frustration.
> 
> That's why I wrote on IRC the other day that FGS needs some care. It's 
> an excellent base to manage our suite of packages (and it does work once 
> you get through those hurdles), but it just needs some polishing to 
> remove those frustrations, and of course to maintain it up to date with 
> current packages.

I'm not too frustrated, but clearly some work is needed to make FGS
more accessable to new developers.  For the time being I'm making a
few notes at:

   http://wiki.osgeo.org/index.php/FGSDevNotes

Once I have some more experience contributing to FGS I hope I'll be
in a better position to talk about whether it would be suitable as
the "OSGeo Linux Distribution" and then trying to get others involved.

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    | President OSGeo, http://osgeo.org