[wpkg-users] package is run one more time after removal

[Rainer Meier]

Hi Simon,

simplesi wrote:
> I believe I published my package in my last post - I think you missed it :)
> It does not have any checks

You're right. Even parts of your response I did not read because it was part of
the quoted text and therefore not obvious that you wrote it.


>> The only difference (and that's what is irritating you I think) is that
>> WPKG is
>> going to verify the package on each run.
>>
> The irritation is that I have removed a package from a profile but WPKG
> thinks it is OK to run the package one more time :)

This is because WPKG first verifies the installed packages which also allows to
"repair" something which is broken. Also uninstallers require some defined
system state in order to work properly. Therefore this helps to assure that the
system is in a proper state when uninstall commands are run.

Moreover as explained administrators get the chance to fix up wrong commands. If
WPKG would not upgrade to the latest version first it would have to rely on the
commands in local wpkg.xml and if the commands there are wrong the package does
not get removed and you end up in an endless-loop with no chance to fix it
Except re-assigning the package to the host, waiting for execution which does
the update and then remove it again. Unfortunately this approach is totally
inconvenient for administrators because if this happens to a group (profile) of
hosts then it's extremely hard to make sure and track that machines got updated
and then remove the package again.

With the update-before-remove procedure an administrator can simply fix his
mistakes and remove the package. So the host will upgrade and immediately
correctly remove the package.


> I don't call that verification - I call that program execution.

It is verification. It's not the fault of WPKG that you did not specify any
checks which allow WPKG to check if the package is installed properly. If you
add checks, then WPKG does real verification because you enable it to do
verification.

However it seems the only problem you have with the current implementation is
that WPKG will re-run the package (which you flagged with execute=always) once
more right before removing it. The reason why this is a problem is not fully
clear to me because the package will anyway run x times on every client (you
cannot control when and how often the machines are rebooted). Moreover even if
WPKG would not execute it once again it might happen that users are executing it
again right before you publish your profile change.


> I can understand why it has been introduced to deal with debugging faulty
> uninstall scripts but don't see why it cannot behave in a more logical way
> for simpler cases with no uninstall commands.

Because especially in the case where no uninstall commands are defined it's very
likely that the administrator forgot about them and then the
upgrade-before-remove command is very essential.
So just dropping the package in this case will leave the packages installed and
this would for sure yield much more bug reports popping up in our bug tracker.

To me it looks like you use WPKG to run some kind of command on startup.
"Choose" sounds a bit like an interactive command which is also not a very good
idea to run it via WPKG (which is usually run in background as a service).
However on Windows ME and older this might work.
In any case I would recommend a different approach - you may think about it...
- Install a service which runs your "choose" commands
- Maintain the service using WPKG
This means that I would create a package which adds the service and verifies
(using checks) that it is installed. If the package is removed WPKG will remove
the service too. Instead of a service you might also use the Autostart, Task
Scheduler, HKLM Run or any other facility.
This way the software you want to invoke is just run as long as the package is
installed. As soon as the package is removed it's not executed any more.



>> But your package assumes to be run on
>> each WPKG run anyway if you specify execute=always, so running it once
>> more
>> should not be a problem.
>>
> Can you imagine the frustration that would be caused to you if the cscript
> engine decided to 
> run a line of code that you'd just removed from wpkg.js for the next run
> only :)

This is quite an inappropriate comparison. WPKG is not executing something you
just removed. By removing the profile entry you're just instructing WPKG to
remove the package on next run - it does not specify how this is to be done.
WPKG implements the most safe way to assure proper removal and the behavior of
WPKG to achieve this can be verified within the code by anyone and some
documentation is available too.

So it's not the case that WPKG just executes something "unexpected". If the
script engine has a (defined) feature that it reboots the machine when I set
some specific properties, then I can perfectly live with that, even if I did not
ask it to do so because there might be good reason to do so.


> Makes things very tricky to debug.

As long as the behavior is clearly specified and there is a way to implement
"my" use case I would be fine with it. WPKG has clearly defined behavior.


> The package I posted here was the simplest package to behave in the way
> described.

As I can see from the definition I got the impression that WPKG is used here for
a purpose it was not made for. WPKG is a software deployment tool. There are
many mechanisms in Windows to assure that a command is run on each Windows start
or based on schedule. Please consider deploying settings/commands which execute
your "choose" commands at the same frequency as WPKG would do but use WPKG to
track/verify that the service is still in place. This is what WPKG was made for.

br,
Rainer