[wpkg-users] Basic behaviour of WPKG

[Rainer Meier]

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.


This has a couple of other effects too. Let's summarize some of them I could
imagine:
A positive effect would probably be that an administrator could see from
wpkg.xml that the package has been assigned once on the system. However by
keeping profile.xml histories this would be possible too.

A negative effect would be that after a while there might be pretty much
packages in wpkg.xml where no remove command is specified and where there is no
corresponding package on server side. Currently this would lead to a couple of
errors because of the "zombie" state of this package. Zombie state means that
the administrator does not have any control over this package any more (removed
from packages.xml).

Another drawback in most installations would be that wpkg.xml files are not
comparable easily any more between systems. Some of them might have additional
packages which have been applied once and then removed before applying to all
nodes - so they remain in wpkg.xml on some nodes and not in others.

It could also become an issue in terms of WPKG execution-performance. Remember
that WPKG will have to verify all packages locally installed. This means it
would have to verify all these on each synchronization too just to find out that
they should be removed and due to this special rule (no remove commands) its
removal is skipped.

This way of handling packages also introduces some question what would happen in
case a package with no removal commands is broken. For example if Office was
applied to a system without remove commands and then the package is deleted from
the server. It remains on the client and the checks are executed on each
synchronization. As long as it's installed it might be fine - but what if the
checks fail (somebody uninstalled office)?
Either it can be ignored (since removed by admin anyway) leaving orphaned
entries in wpkg.xml which are completely ignored. Or it could be re-installed
(which might fail if Office is removed from the server share). Or it could
remove wpkg.xml entry then but this renders the only advantage (keeping history
of installed packages) useless.



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

In addition you're free to switch off the upgrade-before-remove behavior - but
surely you know because it has been implemented on your request.



> > 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 think in most cases a "hunter-seeker" package is less convenient to users.
Just imagine your situation above. You have a package where you did not specify
any remove commands and then decide to remove it from the profile. As a system
administrator I would expect the software to be removed - with the suggested
change the package remains on the system and I need to create such a
"hunter-seeker" package.
And how should this work now? Should this "hunter-seeker" package have
install-commands which remove the second software? Which checks do you define
for the "hunter-seeker" package? How is the "hunter-seeker" package handled and
uninstalled itself?



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

Well, I apologize that I probably did not fully get all your ideas. I kindly ask
you to give us some more insight on your use-case.
If possible make a few examples where your use-case will be in place and why you
can't do that with the current implementation.

I can always try to allow you a bit more flexibility but it's difficult or
impossible to implement conflicting requirements.

I would like to get different opinions on your request too - let people express
if they think it could be helpful or not. I will try to explain possible
side-effects or drawbacks then as I did above. You might try to implement some
of your ideas too and then send it for public review/test to see if existing
users are satisfied with your proposals and if their way of using it is
compliant to the changes suggested.

br,
Rainer

PS. Sorry Simon for sending it twice - I hit the wrong reply button. Now copied
to the list too.