Once you’ve honed your packaging skills, and created some cool application bundles; you’re not done yet.
Having a great bundle installation without the ability to cleanly remove that bundle is like having a powerful engine in a motorcycle… with no brakes. Oh sure; it’s great as long as you’re going forward, but if you need to stop and make changes (for example, if you have to change enterprise mail system clients), you just might have no choice but to re-image every motorcycle. Okay, that’s where the metaphor breaks down a bit, but you get my point.
Anyway, here are a couple issues that I see as important that — if left unattended — could really grow into larger problems.
The bundle “Uninstall” – one should put as much effort in testing and implementing “best practices” for the bundle UNinstall as we do for the install. By default, a bundle’s uninstall actions are simply the Install actions in reverse; this is OK for simple bundles, like a bundle that installs only one .MSI. However, many bundles are more complex. Ensuring your bundle uninstalls without error is also important.
I disable the default “Uninstall” action for most of my bundles and add custom uninstall actions to avoid errors, especially for bundles that install dependent bundles (I generally leave dependent bundles installed). This leads me to…
Dependent bundles – I think most packagers are aware that it is a best practice to determine an application’s dependencies and, whenever possible, bundle the dependencies as standalone bundles to allow the software deployment/management system (for example, ZCM) to manage them. This will reduce errors when an application attempts to install a package that is already installed or uninstall a shared dependency; it also saves time.
If you keep these things in mind, you can get on your bad motorbundle and ride… and stop when you want…