Re: was [Re: [OGo-Developer]] install script modifications and additions suggestions/comments

Kelley G wrote:
>

Well suggesting things and being vocally creative is the easy part. No? 
Its the actual programming and doing stuff that has value. Discussion is 
necesary to a point however.

May I suggest that you develop a spec for the installer first, as this 
will help you sort out step by step what needs to be done. Then work out 
the design. This is your baby so I am only suggesting a method to sort 
out the requirements. The rest of course is up too you. ALways willing 
to comment..

Suggestions:

1. The script should have a mode (the default) where everything is done 
"with-out" user intervention with the only possible exception a prompt 
for the user to identify the ditro and version number. (see webmin 
installer for details on concept and implementation)
- the only issue here is mostly related to apache, its the module build 
locally or downloaded via wget from a repository.

2. The scrip should have a mode that is "user interactive" for each 
component of the installation from beginning to end. By that I mean 
simple cue that step one is complete, do you want to proceed to step two 
y/n? As said it build confidence and undestanding for those who actually 
want to know/learn/undestand what is going on. It has the added value of 
pausing the install after each step to ensure that dependancies are met. 
  IF nothing else it gives you time to review the install notes, 
(typically after the first install barfed and OGo is not live...no one 
really reads this stuff untill they get into trouble..:))

3. The areas that will cause you grief I would assume are as follows:

-distro identification.
-per distro identification of location of postgresql
-per distro identification of locaiton of ngomod dependancies

Now if you design the script in such a manner the specific people can 
provide the data you need per distro and version and that its easily 
pluggable into the main body of the script then the only real 
requirement for the user/installer is to be prompted at the begining 
allowing for selection of distro and version number.

The rest should then proceed to completion seemlessly as all the 
pertinant parts for that specific distro and version number have been 
supplied by people designated to monitor that distro/version and provide 
the data requirements.

For example: I can look after most SuSE products, just tell me what you 
need and I can supply, Plug in the supplied data  to your properly 
constructed script and when the user/installer selects SuSE 8.2 for 
axample all teh appropriate variables are loaded, then checked and 
......bang...... she installs like a charm.

Secondly, if needed I could build the module on most SuSE products 
desired and we can make that available via a repository on line for 
those who dont want to build the module, just download it, per distro 
version, at the time the script gets the rpms. Others Im sure will pick 
up the other ditro's and this is most certainly a task that can be 
shared per distro even.

It is important however to make the ngomodule installation a 
user/installer's choice. In most cases it will elliminate 90 percent of 
the install issues. However this must remain an option if it is 
considered a valid concept, as most will want to security and controll 
of building the module themselves. A choice however build/download 
remains a solid idea in my mind.


Wrt to the scripts design and for an idea of what I mean take a look at 
the webmin installer. Its very similar to what we are discusing.

back to other things more mundane...thanks for the refreshment..

/ch





-- 
OpenGroupware.org Discussion [email protected]
http://mail.opengroupware.org/mailman/listinfo/discuss