Wednesday June 01, 2005 
Wednesday June 01, 2005 The current installer for the product I work on automatically generates an uninstaller. Unfortunately, this is sometimes less than ideal in it's action.
One example of this is that the installer generates a license file, but the uninstaller doesn't make it go away. This is due to the file not "belonging" to any package. I am currently investigating ways round this problem. It seems easy enough for SVr4 packages, but I haven't found the right answer for RPMs yet.
Another issue that can arise is with components that are shared between releases of the product. At the moment, this only affects Linux, where we install some supporting "system" RPMs along with the the product packages. If you install two different releases of the product, and then uninstall one of them, it is possible that the "supporting" RPM will be uninstalled, leaving the remaining product less functional.
The third issue with the uninstaller is that it is not the exact inverse of the installer. That is, if you do a full install followed by a full uninstall, you don't necessarily end up with an unchanged system. Again, this is due to "supporting" items being installed. For instance, on Solaris we (optionally, but by default) install patches.
I think it would be more intuitive if uninstall were the exact inverse of install. This seems to be a good argument for splitting the current installer into a separate "system preparation" step, which would do patching, add the right JDK, etc. and the actual product install. Product install would be exactly reversible. The system prep would not necessarily provide an easy way to reverse it's effects, and certainly would not be undone by the product uninstaller.
( Jun 01 2005, 03:37:54 PM PDT ) Permalink Comments [1]