[FGS] Status / httpd / etc

[Guillaume Dallaire]

On Fri, 2004-09-17 at 16:44, Frank Warmerdam wrote:
> Guillaume Dallaire wrote:

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

Here are the problem I see when using a fat base package: 

When adding more and more new modules to FGS, some modules will have
packages in common with package included from already existing module.

Having multiple version of the same package might create problem with
conflicting version of the same package. It also increases the size of
FGS distribution files.

With the fat base approach (putting common packages into FGS base),
knowing which FGS-base release includes which package in it might become
another problem. The result : A FGS module will only be compatible for
one FGS-base version.


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

Yes it's quite similar. But FGS is agnostic in term of linux 
distribution (and maybe UNIXes) and add something important : a degree
of isolation between the installed system and the FGS application.


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

The FGS dev environment allows anybody to build his own module with
exactly the same headers/environment used in others FGS modules.

Also, with those scripts, I think we will be able to build FGS modules
for others UNIXes easily. 


> 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 did that for one reason. For example, when you compile mapserver with
postgis support, you need postgresql's lib. With "one package one
module" strategy, your are forced to install the whole package: server,
client, lib to run mapserver. This would not be a big deal if it
would happen one time. 

But the same thing happens when you have mapserver compiled with python
mapscript. You need to install all the python stuff. If only need
mapserver CGI, you will have to install python, php, postgresql server,
etc... Things become bigger and bigger.

---

I tried to keep the whole thing simple. For each module, the
dependencies are in its own file. Here is an example for mapserver-base
(which contains the mapserver cgi + command line utilities) dependencies
list:


apache-base:1.3.31
gd-lib:2.0.28
jpeg-lib:6b
tiff-lib:3.7.0alpha
freetype-lib:2.1.9
libpng-lib:1.2.6
libgeotiff-lib:1.2.2
unixODBC-lib:2.2.9
curl-lib:7.12.1
proj-lib:4.4.8
postgresql-lib:7.4.3
ogdi-lib:3.1.2
gdal-lib:1.2.1
netcdf-lib:3.5.1

When installing mapsever-base, the installer call itself to install each
packages listed in the dependencies file, one by one.

Each packages create a directory $FGS_HOME/etc/fgs/pkgs/MODULE_NAME
containing its own installer script which is executed just after.

---

Please send feedback/comments/improvements.


-- 
------------------------------------------------------------
 Guillaume Dallaire              gdallaire at dmsolutions.ca
 DM Solutions Group              http://www.dmsolutions.ca/
------------------------------------------------------------