[wpkg-users] Uninstall element vs Implied Uninstall.

[K.E.Jones at bton.ac.uk]

Hi,

 It got busy around here again. Sorry I didn't immediately respond. I feel guilty
about the "on-the-spot" replies I've sent but I really wanted to think about my
replies to this.

 Hopefully your guru skills will click into place considering the time span that's passed
since I sent the original message!

I was being very naïve when I wrote the original message wasn't I? I thought I'd
better find a good break to think things over properly and it's just not happened
recently :-(

 I'm finding it a bit difficult to word specific comments because whilst
chewing it over a cleaner concept started forming that seemed to address
all your needs and still make a viable and useful feature idea. It also
started me thinking about Zombie handling more deeply, clean ways of
handling behaviour through XML structure and the usual pipe dreams :-)

 Here goes though...

> -----Original Message-----
> From: Rainer Meier [mailto:r.meier at wpkg.org]
> Sent: 13 October 2008 23:32
> To: Jones Keith
> Cc: wpkg-users at lists.wpkg.org
> Subject: Re: [wpkg-users] Uninstall element vs Implied Uninstall.
>
> 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.
>

 Yep. Definitely only in that case. I had a bit of narrow view at the time :-(
Zero marks for me :-(

> 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.
>

 An obvious thought that I totally missed. WPKG is flexible and I was not
looking far enough ahead to appreciate that. (and the comments below!)

> 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.

 I have an interesting variant that has started appealing in my mind that
might fit in without extra parameters and minimal tweaking of the code. I'd
better go into this later though, there's history of thought that would
make it easier to see where I'm coming from. It hopefully makes a lot
more sense than the starting message and hopefully my comments also
help show where it could possibly help the issues you're bravely facing :-)

>
> 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.
>

 Hrmmm yep. Okay, this one I think I actually missed the conversation
on :-}

 I'm guessing that the intention is to use offer regex across the board and
hence the uninstall checks can make use of it?

 I'm assuming that people might then use it to look for something like;

 "^Microsoft Office (Professional|Standard) (2002|2003)$"

 Sorry, I'm terrible at regex expressions but I think you get the essence
of my bad syntax :-)

 That's a good feature but tricky to map into a network of dependencies so,
yes, I understand what you mean and you have my sympathies!

> 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.

 Yep! I actually encountered one the day after I started re-thinking about
this (InstallShield rubbish, grrr!) so I'm agreed on this but I still disagree
'conceptually' as that being a blocking argument ;-)

[Update... and now I also hit a similar problem with the VLC Client Nullsoft
installer but at least I could hack their installer code :-)]

 A lot of MSI based packages don't behave in this way. Windows installer
"massages" the process so that a silent install leads to a silent un-install.
It's not always perfect as msi programmers can make mistakes too! It's 'mostly
harmless' though !

 On occasions, it's not unrealistic to have some faith that people should
be testing their installs before deploying them. That's probably why I
disagree with you here. If an uninstall string doesn't behave silently then
obviously WPKG already has that extremely well covered by handling it
manually.

 I'd better get this idea out, it's probably very irritating!

This is only a thought ("a what if?" if you'd prefer) but...

 What if WPKG supported;

 [no <remove> element is present]
 <remove/>
 <remove cmd=''/>
 <remove cmd='<something or other>'/>

 but gave them different but documented meanings?

 It's still a bit of a fuzzy idea but you mentioned to Brian in a recent message
(wpkg-users Digest, Vol 12, Issue 15 has it in there) some solutions to his needs
that took advantage of dummy commands so I was just wondering if an idea like this
might appeal.

Perhaps having;

 1) No <remove> element at all;
   Which indicated that the package never gets removed?
 2) <remove/>;
   Which indicated <upgrade> elements should install "over the top".
 2) <remove cmd=''/>;
   Which looked up the package name and followed the command in the uninstall
   keys.
 3) <remove cmd='<something or other>'/>;
   Which just runs the commands as WPKG would normally do.

 That's just a single interpretation.

 There seems to be so many possibilities here about how you could design
"interpretation" into what WPKG does but avoid changing the syntax of the
XML and causing aggravation for the Web interface and legacy use. It seems
a really subtle way of doing things intuitively whilst maintaining compatibility.

 Effectively it's modifying the "business model" not the data files structure.

 I think it might be an interesting concept to look at filling in the
'undefined' behaviour of many of the elements and maybe spending some extra time
on planning out what it all means. I guess this was really where that "behaviour"
comment originated and it's now pointing me in the direction of thinking much more
deeply about WPKG as a whole just to be able to come up with some pipe-dream
ideas that might appeal to you.

 I guess you've got a few thousand of those yourself though :-)

 It would be really cool to chew that over at some point!

 I'm hoping you can see where I'm coming from. It seems like an elegant use of
the attributes and structure of XML rather than pushing WPKG.JS to handle more
and more attributes and elements.

 It certainly made me re-think the idea of an extra parameter to implement it!
:-). Who needs a parameter when the XML can spell it out for you ? :-)

>
> 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).
>

 Yes. I understand that one. I'm hoping that the description above really
deals with this neatly. The phrase "less is more" hopefully should help
illustrate it. The idea is to leverage the blank spaces between commands
by looking at the XML structure and usage itself. I really think that it has
a lot of potential!

>
> >  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.

 Bear in mind that people CAN and SHOULD test silent installs whatever
way WPKG handles them. GIGO.... garbage in, garbage out. Although
most of the time it's me checking I'm not speaking garbage ;-)

>
> 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.
>

 On a simple scale and with the refined idea I'm proposing it might still
achieve this but it still gives scope to not change things much for
yourself and others if it can be neatly planned to not affect other code.

 I've actually often wondered if WPKG could be smart enough to identify
some of the installer suppliers. It would be an interesting theory to
try out. I would have thought that it was relatively easy to give WPKG
a go with MSI files but even then I've encountered some awkward ones
that aren't predictable (see Note!).

 As for InstallShield, Nullsoft and others, I guess you could *try* but
it's very much dependant on the quality of the installer designer again.
I doubt it's really worth the effort except for MSI packages.

 I don't think I had it in mind when I blurted this all out. I guess I was
just trying to get my own head around other things :-)

> 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.
>

 Well yes, I guess it would but I'd figure that that might be combined
with the uninstall key lookup I'm suggesting above and would make it even
smarter :-)

 Perhaps it could cascade down through various ways of uninstalling but
I think the essence of my thoughts above was to find a neat way of triggering
"programmed" response vs "automatic" response with as little impact as possible.

 It certainly makes it look more modular and more object orientated in my head.
What do you think?

>
>
> >  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.
>

 I'm still feeling a bit silly about it, but I guess I got all tangled up
with the idea that I hadn't really clearly understood my own thoughts (as usual)
and just reacted. Thank you for being kind and making it a positive thing!

 As you can see it spurred me on to think deeper and I'm sorry that I'm
monopolising your time when it's already a weight on you to come up with
all the programming. It just seems good to get some thoughts out and chewed
over by the experts!

 I just wish I hadn't talked so much :-)

>
> >  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.
>

 Yep. As usual, I had a few more thoughts about this. The first thought
was hopefully mentioned way above here i.e. That at the end of the day
the package needs to be tested and if it doesn't work then it needs the
extra stuff WPKG can do to help it along. That's the big selling point of
WPKG to me, it handles the stuff that other methods would need me to
handwrite a new installer for! [Believe me when I say I've been there, done
that and have the scars to prove it!]

 The secondary thoughts I had though were mainly inspired from experiences
with using Active Directory deployment methods. It's also starting to fix
itself in my head where WPKG might leverage things to build up an effective
way of handling zombies.  (With my head it's a very slow process!)

 Part of what I was thinking about when I wrote the first message was just
an unstated expectation of how I thought WPKG would deal with zombies. I'm
doing my first upgrades and I'm just finding it hard to not make things
zombies. I expected WPKG to help me out but I guess I didn't really
think about how particular my needs were or examine the code deeply enough
to work out the best way of deploying stuff in the first place. :-(

 This might be worth a separate thread but;

 Active Directory uses group policy which neatly propagates around the domain.
WPKG also uses its own form of this i.e. the installed package report [name
omitted because it can be renamed :-)]

 Perhaps the best way of handling zombies is to extend that report to
include the package definitions as well? Perhaps it could accumulate a
historical list? I guess it's a thing that would need some good design work.
(And probably a few 1.0's added to the version?)

 If a package enters zombie status then at least you might be able to go
through those or a history and try to uninstall it?

 There are some pretty obvious issues, such as, file sizes for the history,
missing resources, extra XML to manage how the 'independent' client should
actually behave but that's probably the only way you can give the admin a
way of being in control of zombie processing.

 I guess this might be a WPKG 2.0 (maybe 3.0) thing though :-)

 It does intrigue me though and I'll try and find some time to really get to
know the issue. (and try not to bother you too much as well!)

 My initial thoughts are to separate the "action" (i.e. how WPKG should treat
zombies) from the package definition itself. This is probably why utilising the
XML structure appeals in my head. Literally the way the XML is interpreted could
indicate the "behaviour" WPKG has. I guess that's why I also tripped out talking
about "behaviour" ideas. [My company should hire my subconscious, it's way better
than the conscious me!]

>
> > 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.
>

No problemo!

 The bugs I wanted to report are being a bit of pain. I'll have to test them
thoroughly before I can actually say for sure they're not weird JScript
responses to stuff I've tinkered with.

 As you can guess I'm playing with experimental tweaks to WPKG so I'm conscious
of tracking my own code thoroughly to eliminate it from the equation. The
issue I had was a crash when I used dinfo to output an integer value which got
caught at a much higher level than I expected. I think it's just a failure
in Jscript to coerce values to strings but I'm not entirely sure.

 I'll do some more work on it first to make it certain it's a bug in WPKG but
it might end up as a "getting round a JScript behaviour" issue rather than
being purely a bug. The messages about stack issues are making me wary about
Jscript itself. It just "feels" wrong because coercion *should* have worked.

 I know what you mean about finding time. I'm aiming to release a new
WPKG.Utility version shortly. I'm really conscious that I don't want to
monopolise the Wiki so I'm just holding off for a while so that I can get
these few thoughts out, work done and then I might be able to squeeze in a
website to reduce the wiki entry for WPKG.Utility to a link instead.

 It's probably a bad idea for me to edit the wiki with all the wandering
thoughts I've got in the code so far. I just talk and talk and talk :-)

 It'd be lovely to see familiar names popping up in the hit log when I've
got it all sorted though :-)

>
> br,
> Rainer

br^100+kudos^100,

Keith

PS: I'm *almost* on top of the versioning of WPKG.Utility... Next time though,
remind me not to aim at a framework. Handling version numbers down to the
function level is an absolute nightmare!

PPS: WPKG.JS v1.2.... No pressure but... ooh... I'm going crazy waiting :-)

PPPS: This is probably the silliest thought of all but I'd like to have a bash
at trying to assemble these ideas into a working model so you can try out
the concepts without also having to write the code. I can write them up
and put them on the new site for WPKG.Utility but it might be interpreted
incorrectly as a fork rather than a thought experiment.

 Would you prefer I put derivative versions in as bugs so you can play with the code?

PPPS: Jorge stuck in some fantastic contribs that really deserve a good attempt at pulling
into the code. Some of them have really got my thought juices going but I'm just a bit worried of overloading you with ideas!

PPPPS: I'm going to send this now because I've re-worded it about a thousand
times now trying to not sound too eager, too pressuring or naïve again :-)
Thank you for your patience! WPKG just has so much potential!