[FGS] Status / httpd / etc

[Tyler Mitchell]

Hi gang,

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

I don't have a clear opinion on the fat versus thin base methodologies.  You 
have both made logical arguments for and against each.

I do have an opinion on a couple related points though.  Module/base file 
sizes are irrelevant to me and, I believe, to the community in general.  That 
is not a factor in my book.

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

I see that the "base/module version" dependencies can also become an issue 
quickly, so I appreciate that point being brought up.

Our original intention was also to keep the number of 'packages' as few as 
possible - hence a larger base package and fairly thin modules.  However, I 
don't mind increased number of packages if it can help maintain the 
project(s) over time.  I've used the installer several times and am convinced 
that the complexities of the dependency tree can be handled without too much 
pain on the users' part.

What I'm not clear on is the process for creating them - I guess I need to dig 
further into your CVS code eh?  I feel we got the building environment down 
to being pretty simple in the first round - how does this environment change 
with this installer/packaging philosophy?

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

Sounds good.

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

This certainly was not on my radar either - I never thought of doing this.  
I'm not sure I fully understand the purpose here or who the target audience 
is.  Can you elaborate a bit more on what you mean by "his own module", with 
an example perhaps?

> 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 follow you here and think your approach is simpler, at least in the cases 
where lib, bin and dev files are easily separated.

> Please send feedback/comments/improvements.

I'm interested in pursuing things further along these lines, but need some 
coaching on how this would change my building strategy.  Maybe you have 
already tried to do this, but I still don't understand.

Thanks for taking the time to explain and debate these topics guys.

Tyler