Forum OpenACS Development: Re: install documentation of aolserver

Collapse
Posted by Gustaf Neumann on
Couple of answers:
the docs contain ... innumerable short cuts and a maze of cross references ...
sorry, i don't see the docs as a shortcut, i rather conceive these as a maze. the script is for me a concise, executable shortcut, stating exactly, what's needed and how to install it. maybe, i belong to a different target group. i went through the maze in the past, tried to guess what's correct/wrong/outdated/not relevant etc.
... depending on the flavor of Linux one is using and the options one wants to install...
addressing all flavors is very ambitious. the flavors are moving targets. explaining the differences for all versions is a lot of work, and i have certain doubts, that this should be the goal of the OpenACS documentation. The script is a huge simplification by providing a full installation for the mainstream platforms. Every sysadmin knows what to do with it.
Readers have to wade through and attempt to ignore a significant part
my words: why do they have to do so? What is the target group? sysadmins? hardly. end-users? hardly.
Gustav, the "8.4.7" in the Tcl-install page is only showing an example of what a function returns. Is that really the largest criticism you can express?
well, at the time of my posting, the page was recommending to install 8.4.13. In the past i have altered more than once references to 8.4.13 into 8.4.14, but it seems that it was changed back. I was going to change it again, saw the comments by jiml, saw the 10 or more install pages on the left, wondered whether tcllib or XOTcl might be a subsystem, therefore the it should go to a different page, or not, wondered, what is meant in general by a subsystem, wondered, whether one should add warning not to run OpenACS on a reasonably busy site with Tcl 8.4.7, looked on my watch, saw that i have to prepare some meetings, and asked myself and the forum, whether or not this is a suitable and maintainable approach, what we are doing. Only criticism? please read me posting again. Btw, who is Gustav?
Why not focus your constructive criticism...
My posting is more constructive suggestion (by suggesting an alternative path) than a destructive criticism (saying what's wrong). I have a demanding job which has nothing to do with OpenACS - so i have limited capacities and i try to help by providing some support in the forums, in the core team, helping to fix the problems of openacs.org, or developing xotcl-core/xowiki further, and so on.
Has the OCT decided where the "supported" standard location is for installing xotcl and tcllib in the context of the reference platform
The OCT does not have to decide that since it is clear that the standard place for these components is installed aolserver tree, that is: aolserver/lib, the same place, where tdom should be installed to (and tclwebtest as well to be able to run the regression tests).
Christian: Sure, packages are not always the very latest; tcl8.4 gives you 8.4.13 (with thread support). How is 8.4.14 superior? Is it worth the clutter?
8.4.14 has several important bug fixes, especially for multi-threaded Tcl applications (aolserver/naviserver are among the largest and most demanding multi-threaded Tcl applications available). A couple of Tcl commands in versions up to 8.4.13 used C library functions that were not multi-thread safe. Zoran fixed this for 8.4.14. Clutter: Tcl should be installed with --prefix=/usr/local/aolserver, or aolserver-4.5. I strongly recommend to compile all Tcl C-extensions and aolserver modules with the same tcl-include files, which should be installed in .../aolserver/include. If one mixes versions, he asks for troubles. By installing into the aolserver install tree, there is no conflict with system updates, or other applications needing certain versions of tcl, etc.
Dirk: A regular OpenACS developer should be happy with the packages provided by Debian stable: to my own astonishment all the necessary packages for OpenACS (save the dreadful daemontools) are even in the oldest possible Debian release.
Dirk, in general, i agree with you: it should. The question is, what "being happy" means: being able to compile and start or to run reliably. Aolserver/naviserver are demanding applications. We have a few quite busy openacs installations, some of these had crashes that went away by upgrading to 8.4.14. It is certainly less work to install tcl within the aolserver tree and compile the needed c components with that version than arguing with package maintainers. What do you do if they release a version of tcl that is not tested with aolserver? What's so bad about giving aolserver it's own Tcl version, with which it is known to work reliable? Are you concerned that Tcl might not compile? About the time Tcl takes to compile? About the disk space? Over the last half year i made at two important fixes to the aolserver c-sources, one of these was stopping openacs.org on a nightly basis. It is not clear, when the next version of aolserver will come out, and if or when it will make it's way into the various distributions. Malte's script takes care of these things and it is less work to use it.

Certainly, having package maintainer for OS-specific distros for aolserver, the needed aolserver-modules, openacs and dotlrn would be great, but we don't have it. Btw, one of my people has developed such a suite for FreeBSD, but it is not committed yet(see: http://www.matuska.org/martin/freebsd/).

Hope this helps.

best regards
-gustaf neumann

PS: Torben, sorry, if you feel personally attacked, that was not my intention.

PPS: That was my openacs timeslot for today.