A few quick remarks about installers
By terryh on May 13, 2005
One of the things I work on here at Sun is creating the installer for the Sun Studio product. This is the native compilers, ide, performance anyalser etc. - not to be confused with Sun Java Studio.
I've been working over the last several releases to improve both the quality of the installer, and the customer's experience in using it. Unfortunately, I don't get a large amount of feedback on how I'm doing, so anyone out there in blog-land, feel free to email me if you have comments. I currently have the opportunity to start over with a blank sheet, since I've been asked to come up with an installer for an internal prototype our group is working on. So now is a good time to reply!
Anyway, one of the problems I see with the current installers is that there is a combinatorial explosion of possibilities, which makes it
- hard to test, hence hard to achieve high quality
- hard to document
- hard to use
A second challenge that we have is that the current installers conflate two subtly different activities together. We do system preparation and product installation all mixed in together. An example of a system preparation function would be installing a Solaris patch, or installing an extra system RPM on Linux. Product installation proper should only consist of installing the product packages and creating any configuration files required by the product. An example of a configuration file would be the
license.dat file containing the serial license. The fact that these two activities are not cleanly separated makes it hard to use a server-based install approach, where numerous clients can NFS-mount the software from a central server. It also has implications for uninstalling, particularly where multiple releases of the software are installed on the same system.
So, there are a couple of issues. I'll try to expand on what I might do about it in the next post in this category.