[wpkg-users] Uninstall element vs Implied Uninstall.

[Rainer Meier]

Hi,

K.E.Jones at bton.ac.uk wrote:
> Hi Folks,
> 
>  I appreciate this would be a massive "behaviour" change for WPKG but it could probably be designed to be settable via command line or config.xml as a switchable behaviour.

Let's analyze the request.


>  Seeing as WPKG already scans the registry for Uninstall keys to make checks, would it not make sense to assume that they are used if an uninstall element isn't supplied? They are most likely to contain command lines for uninstalls.

WPKG is designed to handle various types of packages. Lots of packages
are not even verified using the "uninstall" type check. However you're
right that in case (and just in this case) there is an uninstall check
specified WPKG might eventually read these information from there.

Unfortunately there are a few problems here:
1. As already mentioned not all packages are using uninstall checks and
therefore WPKG does not know to which uninstall entry it should refer to.

2. In some cases I even use uninstall checks when the package is not
directly related to the uninstall entry I am referring to. For example I
use QuickTime Alternative. I defined two uninstall checks for "Quicktime
Alternative" and "Quicktime" (the original one), both checks used within
an OR logical-connection. So if a user has the "real" quicktime
installed, this yields true for my "quicktime" package.
In such case WPKG could not know which package (the package refers to
two uninstall entries) should actually be removed.
As a result I think WPKG should never use the information provided in
checks. Instead the package definition could probably be enhanced to
provide an attribute to specify the associated uninstall entry.

3. Given the case described in (2) above there is a further problem that
future WPKG versions will support wildcard/regex matches within the
uninstall string matching. In such case the reference to the uninstall
entry might match multiple entries. So WPKG would have to try removing
all of them which could also lead to unexpected/surprising results.

4. This is a very important point. I think the usage of such "automatic
uninstall string detection" will be very very limited. The uninstall
entry within the registry sometimes provides an "UninstallString"
string. However it is usually NOT silent - which means it is useless for
WPKG. In some rare (unfortunately very rare) cases there is a value for
"QuietUninstallString" too. This command usually uninstalls the program
silently. Unfortunately I already discovered some applications where
even the QuietUninstallString is not silent. So anyway an administrator
will have to verify the contents very carefully.

5. Some administrators (including me) are using packages where the
uninstall command is not defined within the package definition on
purpose. I do this sometimes because it makes no sense to remove the
package later on. Even if I remove it from WPKG. So I just leave it on
the system.
Of course in such case one might omit the reference to the uninstall
information as proposed in (2).


>  It would certainly simplify package definitions.

See above. In most cases it will not be possible to read proper
uninstall information from the registry as almost no program provides
correct silent uninstall commands.

However I discovered that some uninstall commands (as found within the
"UninstallString" string within the registry) can be made silent when
adding some parameters. Windows installer packages (msiexec) usually
work silently if "/qn" is added. NSIS installers usually provide an
uninstaller helper exe file stored within the install directory which
can be called using the "/S" switch. But this does not always make them
to work silent.

So probably an implementation could look as follows:
- WPKG checks if uninstall commands are provided. If yes, then it
executes them and exits. If not, read on...

- WPKG reads the optional attribute which specifies the associated
uninstall entry.

- WPKG looks up the "QuietUninstallString" entry and executes it.

- If no QuietUninstallString is available WPKG stops to execute any
further commands unless one more attribute like
uninstallSilentSwitch="/qn" is defined within the package definition. If
it is specified, then it reads the "UninstallString" string (non-silent)
and adds the parameter as specified within the uninstallSilentSwitch.

Hopefully this initiates a really silent uninstall.

In general I have the feeling that this could be useful for a very very
limited amount of packages. But nevertheless I think in some exotic
cases it could be useful. Adobe Reader could be one of them I think as
it uses an MSI uninstall string as follows:

UninstallString="MsiExec.exe /I{AC76BA86-7AD7-1033-7B44-A90000000001}"

Unfortunately the UID used changes on each release. So an administrator
would have to update it each time.

Given the proposal above an administrator could omit the uninstall
string, define "Adobe Reader.*" as the uninstall entry reference and a
uninstallSilentSwitch="/qn" switch. So on further updates there is no
need to read and update the UID within the uninstall command definition
on the package.

As you can see Adobe Reader is also one of them NOT providing a
QuietUninstallString entry within the registry.



>  I know I'm being naïve and missing something here ? Maybe some documented future plans or something but I've trawled through the code and can't see where the keys are used anywhere in the install/uninstall process (in 1.1.0-M6 so I thought I'd mention it).

It's good to ask naive questions. This gives some hints to think about.
So now I thought about and gave some hints. As you can see it is not
exactly as easy as you might have thought.

So you're right, the UninstallString/QuietUninstallString entries are
not yet used at all.


>  It just seemed like a natural behaviour that might also assist zombie handling.

And here I have some concerns about. I am not sure if it really helps or
if it could be even more misleading. The administrator might think that
he does not have to provide proper uninstall commands for each software
package. Unfortunately the automatic uninstallation will probably work
for 2 out of 100 packages which provide a SilentUninstallString. For all
others it will fail - or require an additional switch to be specified.

If the switch is wrong or simply the uninstaller does not really work
silently it might lead to unexpected behavior and might be hard to debug.
For example - try to create an NSIS based installer/uninstaller. The /S
switch just sets a property - you have to read that property manually to
act accordingly (not asking for any user interaction). If you do a
mistake your installer will not be silent.
A good (or in that case very bad) example is TortoiseCVS. It claims to
be silent but on Vista-64 it displays a prompt to confirm that the
software is not supported on this operating system - even if they claim
that it is fully 64-bit compatible since a few versions. So somebody
simply did not remove this check/warning. And yes, it even appears if
you use the silent switch properly.


> PS: I might have a few bugs to submit shortly. It's been mad here and I'm way behind all the stuff I'd *like* to do :-)

Feel free to commit the bugs to bugzilla - it's easier to track them
there. I try to find some spare time to continue wpkg.js
development/enhancement.


br,
Rainer