[FGS] Status / httpd / etc
tylermitchell at shaw.ca
Tue Sep 21 01:11:44 EDT 2004
> > 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.
> > > 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.
More information about the Foss-gis-suite