[wpkg-users] Basic behaviour of WPKG

[Pendl Stefan]

Rainer Meier wrote:
Hi Simon,

simplesi wrote:
> > I've been thinking about WPKGs default behaviour (following from earlier
> > discussions) and I'd like to start a genuine discussion on changing its
> > current behaviour.

OK, let's try to get a common understanding of the ideas first.

> > Currently, WPKG will attempt to remove an existing package from the local
> > compuer wpkg.xml file if it decides that an existing package is no longer
> > referenced for that computer, regardless of the lack on any remove cmd in
> > the package.

That's true. If a package was assigned to a host before (the only way they go to
wpkg.xml) and then removed by administrator then WPKG assumes the package should
be removed from the host. The definition in profiles.xml (package assignment)
defines the supposed state of the client and wpkg.xml represents the
current/actual state of the client. Comparing them allows us and WPKG to find
out what has to be modified to reach the state supposed.

> > I believe that it would be better if it didn't and that it should only
> > remove a package from wpkg,xml if it decides that the package no longer
> > applies and there is a remove cmd in the package.

OK, let's first be sure that I understand this correctly. The first part means
that WPKG should remove the entry from wpkg.xml (as it is now) but only when the
special condition "at least one remove command is defined" is true.

This means that in case you do not specify any remove commands the package would
remain win wpkg.xml even if the administrator removed it from hosts.xml.

> > Also, the current default behaviour of attempting and upgrade before
> > attempting a removal doesn't feel to me to be the best way of dealing with a
> > faulty remove cmd as I think it is not a logical action to take.

Well in theory it's a bit "special" but for me and many others it seem to work
properly and was helpful in many cases. The administrator only needs to take
care that the latest package version is perfectly in shape and removes properly.
So an admin does not have to worry about what would happen when he removes the
package from a profile because he has in mind that some old versions he forgot
about the remove commands and if a PC was not updated for a while the removal
would fail on next run.

> > I can understand that it allows for multiple attempts to get the removal
> > right but I think that if a removal has gone wrong, it would be better to
> > write a new "hunter-seeker" :) package to correct the error.

These "multiple attempts" should be done on test systems. But there might be
cases machines in production behave differently - so fixes to the package might
be required sometimes (not only fixes to the deployed software).

> > I don't think having lots of different flags is the way forward and it would
> > be better to reach consensus :)

I agree that the number of flags should be kept small. However currently WPKG
just needs a few. In basic installations you can use 'cscript wpkg.js
/synchronize' and that's it. All other settings can be put to config.xml.
Remember that the /noUpgradeBeforeRemove was just introduced on request of you
while I don't think anybody except you is using it yet. But I accepted that your
use case required it.

-------------------------------------------------------------------------
Hello,
If I have no remove command for a package, I usually create a custom registry key and value, which can be checked for existence and removed to include a successful remove.
Keeping a package installed, seems not a good thing to me, since I know what to remove and what not.
There is already a switch to turn package removal off.

The upgrade before remove has saved me hours of running cross the company, needing to turn on each computer to correct remove commands, that did not work on some machines.

An additional clean-up tool is not required for me and I would not like to need one, I have currently all set up to work properly.
Using a virtual computer to test your packages is helping immensely.
Checking the log files is a timesaver too.

---
Stefan