Section 9.6. Installation IrritationsShip Happens


9.6. Installation IrritationsShip Happens!

Some common issues with installations from the project's point of view are:


Testing installs

Testing installs is hard since a single installer can change the entire environment of the machine on which it was run, and can do this in ways that are hard to revert. One approach that can help is to use Norton Ghost, g4u (Ghost for Unix), or VMware to create copies of the system software, and to restore the machine's original state after each test install.

Automating the process of testing installs is also hard because many products' installers are GUI driven, and it's also complicated to determine whether an install really succeeded or failed.


Testing localization

Ideally, you want to test every localized installer on an appropriately localized machine. This problem grows linearly as you support your product in more languages, and automating this is hard.


Automating installer creation

Automation of the installation tool as part of a release process, to create the installers for the product, is also tricky. Command-line use of installation tools often doesn't seem to have had the same amount of testing as the GUI versions of the same tools.


Installing third-party products

Bundling other products with your own product in the same installer is a common requirement, since it makes installations simpler for customers. Simply invoking other installers from within your installer is not very elegant, since the same questions may be asked of the customer over and over again. Catching broken installs and uninstalling other products is also hard. Some of Microsoft's products provide versions of themselves ("merge modules") that other installation tools can integrate into their own installers.

Some irritations that customers often find with products' installers are:


Installation chains

If you know what other software is already on the machine that the installer was created for, then you can bundle everything that your product needs into one installer. This is often the case for products for Windows. For products for Unix, especially open source products, the chain of other software that also has to be installed is daunting to many customers. Sometimes the chains turn into circles, or fail frustratingly when you are six levels deep.


Inappropriate privileges

Why should a user have to be root to install a package to her own Unix home directory? Why should your child need to have Windows administrator privileges just to install a simple game? Too many products assume they have to be installed as the superuser on a machine when they don't really need to be.


Corrupted installers

Adding a virus or trojan horse to a publicly available installer is a classic approach for infecting other machines. Consequently, making sure the installer you released is what customers actually download and run is going to become even more important. I think that signed packages and installers will become a requirement for all platforms, just as they are now for embedded Windows devices.


Uninstallers

How does a customer know that uninstalling your product won't damage some other vital part of his system? Just as installers describe what they are going to do before they do it, thus giving customers a chance to cancel the installation if they're not comfortable about something, so uninstallers should provide detailed information about what they are going to change. Cryptic messages like "Couldn't remove all the files" are really irritatingthey could at least say which files, and why they couldn't be removed!


Lost data

No data generated by someone using your product should ever be deleted, even if she unwisely stored it in the same directory where the product was installed; all customer data is sacred. This data includes how the customer configured your product.


Multiple versions

Make it very clear before an installer actually changes anything whether two versions of the same product can coexist on the same machine. If not, then explain how the customer would be able to restore the previous version if there are problems with the version currently being installed. If this can't be done, then the customer may need two machines, one for production use and one for development and testing new versions of various tools.



Practical Development Environments
Practical Development Environments
ISBN: 0596007965
EAN: 2147483647
Year: 2004
Pages: 150

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net