[FGS] Status / httpd / etc

[Frank Warmerdam]

Guillaume Dallaire wrote:
> In building the mapserver package, I ran into some issues about the base
> package :
> 
> - Conflicts between headers of already installed libs on development
> machines and those installed in the FGS base directory. (gd, jpeg, krb5,
> etc) : For example : currently, gd.h isn't in the fgs-base's include
> directory. The system's gd.h is then used. If you build a new package
> using another machine, you may not have the same version installed. It
> opens the door to many problems.

Guillaume,

I'm not sure what krb5 is.

I agree that we are in a fragile situation with regard to system include
files.  I would really like the FGS build system to be stable if at all
possible.  I think it is quite important that FGS built built on a
relatively old system to avoid depending on recent libc stuff that might
not be available on all target systems.

For something like GD we should clearly be building our own as part of
fgs, and installing include files into the fgs include tree.

> - How to decide when a package is included in fgs-base package ? Why not
> to have a very small base package with a package management script that
> install package's dependencies itself ? 

Well, this can be a matter for different opinions of course, but the
route I have been pushing is a fat base package to keep the whole
dependency tree thing simple.

> To do it, each package only need to list its dependencies in a text file
> that the package management script reads. I made some work on it and it
> works very well.

I looked through what you did a bit, and it looks nice, but I feel like
we are re-inventing RPM or Debian style packaging.

> Also, I wrote some pieces of bash codes that
> download/extract/configure/make/install each packages. It compiles the
> packages by calling the fgs_configure script. The fgs_configure script
> executes :
> 
> $ ./configure --prefix=$FGS_DEV_HOME/built
> --enable-this-lib=$FGS_DEV_HOME/lib .... ... 
> 
> $ make clean all
> 
> If no errors occurs, the fgs_install script does a make install. All
> files are copied in the built directory. Then it installs only required
> files (no headers) in another directory that will be the FGS package.
> 
> Currently, I concentrate my effort to build all the softwares needed to
> run mapserver/php_mapscript with apache 1.3.31. All required libs are
> built except those installed on all linux system (libc, libm, etc.).

As I understand it, your goal is that by checking out all the stuff
from fgs-dev CVS one could re-download all the package and rebuild the
various FGS packages, is that right?  This was never really a goal I had.

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.

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