Linux

This is pretty much what I wish I'd said.

An aside - we have all experienced dll Hell at one time. This was/is caused by the fact that PC software developers do not have compunctions about overwriting existing dll's with a version of the dll 'they have to have' during installation. That seems to be what you are advocating.

One of the apps I am sysadmin and chief whipping boy for brings $US280 million revenue per year. Bills utility customers. Your uninstall implementation screws that up and my company will go after you mercilessly. Got a spare $30 million? This is what you are dealing in UNIX, and even Linux. We do not patch Windows servers for the reason I just mentioned. We go thru a horribly painful redeployment periodically.

One is on now.

We have four experienced Windows guys trying to upgrade from XP boxes to Windows 7, about 600 boxes. There are about 80 of those boxes they simply are going insane over. Mgt was getting cranky about it until we got an important person out on the floor to witness what was going on. Now they are thinking Linux desktops.... Meanwhile we are using Windows 2003 servers to let users runs apps they cannot run on their desktops.

Yet another thing I should add is that I've occasionally fought with installers that are over-paranoid about dependencies. Things that weren't prepared for the future, unable to recognize newer, backwards-compatible versions of its dependencies, and thus unable to install itself on systems it was perfectly capable of running on. Just another reason that trying too hard to outsmart your customers is shooting yourself in the foot...

The customers buy my software specifically for the purpose of managing their PCs, including installed applications, and installed applications are updated only on their specific orders. This is the exact function for which they buy my product.

There are already plenty of packages to manage systems. Aside from intense scripting, there are no other options.

Frankly, I have never been impressed with any software that tries to do what yours is trying to accomplish. Any other kitschy attempts will likely break a system. You may try image based rollbacks, but realize that could be disk intensive, take up lots of space, and leave the system broken in some cases. btrfs is a way to try to fix this by taking snapshots before a patch, with the ability to roll back, however that relies on the file systems being btrfs, which is still a work in progress, and requires a boot loader that can show you the snapshots. That part doesn't exist just yet.

Aside from having generic kickstart/autoyast etc images to rebuild a machine quickly and then apply their packages again (Spacewalk, RHN Satellite, SUSE Manager) you have little use for the tool you are building. Besides, with the three items listed, they do exactly what you want to do already, and Spacewalk is free (however the built in Oracle Express is severely limited, and last I looked the Postgres version was lacking in features).

Apparently, my customers aren't of the same opinion.

The product which doesn't exist? If they buy your hackneyed product then learn their mistake, they are going to be very unimpressed with you.