OpenACS and the software it relies on are not Apache. The main difference is that you can install one version of Apache and everyone on a machine can use it. It is a system wide service like tar, less or whatever. AOLserver is not a system wide service. You can't build AOLserver with the standard Tcl distribution, you need to enable threads and other things. You may not want AOLserver to rummage around the entire system looking for Tcl packages which may also not have been compiled with the correct switches.
On the other hand, just try to install a new version of Apache on an old version of Linux. Forget it. If you have an older machine which still works very well, but has an old OS, you are totally screwed if you want a new Apache.
AOLserver has very specific, but easy to meet requirements. These requirements are not found in the standard installations. Beyond that, OpenACS and AOLserver are best considered as user applications. A single user installs and maintains all the components, and if another user wants to do the same, there is no problem. If software was installed to a central location, management would eventually, maybe quickly, become impossible.
Now, that was just a description of the basic problem, what is the solution?
App-install, although far from ready for general use, had a particular philosophy: hierarchical installation.
Each component has an associated installation file. The file contained more than just a script for installation. App-install would read the file and step through the instructions. It might prompt the user for data, displaying the default and allowing an override. The override could then affect additional defaults. Once these were set, a series of shell commands could be executed. A number of common operations were represented in the file at a higher level than simple shell commands, like creating and writing file content, changing file modes, sudo for certain operations.
Some installation files were higher up in the hierarchy. These files just contained links to other installation files, and/or the associated tar.gz file. App-install would then simply loop through these handling each in turn. In some cases the default variables in one install are reused, so you don't have to keep track of these details.
So the point was to have component maintainers create these relatively small files, and then a higher level maintainer would combine the parts they like into a new bundle. If one part of the bundle changes, the maintainer only have to change a few lines of one file and create a new version.
Once you create one of these files, you can install the sofware with the same information each time.
Then the maintainer just says which file to grab for a particular cases. When there are problems with an installation, the frustrated user can just post the entire output of the installation, because all of it was recorded to a single file. There is no mystery about what the user did or didn't do, or what failed to work as expected.
Examples of what these install file look like are here:
).