[wpkg-users] Behaviour of WPKG

[Rainer Meier]

Hi Johannes,

Johannes.Brix at evidian.com wrote:
> I have also a topic for the general behaviour:
> 
> WPKG loads at start the local WPKG.xml into the memory.
> Then, it executes all pending tasks.
> At the end, it writes back WPKG.xml to the PC.
> 
> And here is my problem.
> When the total job fails for any reason, the WPKG.xml is not updated,
> although some tasks have been executed successfully.

In which cases did you experience problems that wpkg.xml is not committed?
In fact this should happen only in the following cases (add more if you know
about more):
- WPKG encounters unrecoverable internal error (exception). This case is
supposed not to happen at all.

Well, that's it - I don't know about more cases where wpkg.xml is not updated.
The case where a package is not removed/added to wpkg.xml when there is a
pending reboot is intended. WPKG just adds a package after all commands
terminated properly without requesting reboot. Else it would be possible that a
command actually left some uninstall entries in the registry, WPKG would accept
it as successful but on next reboot the software is not there. But I guess we
are not talking about that case.


> A new run will do a lot of senseless actions, because WPKG.xml doesn't 
> reflect the real status.

Well, i it crashes (the only case I could think about where wpkg.xml is not
written) then it might run through a couple of additional commands. In practice
it's unlikely that more than 10 packages are update din one shot. Actually on
all my systems it's usually just a single package which is
updated/changed/touched on each run. So this one might be re-run.

The current architecture of WPKG would allow to re-write wpkg.xml each time an
entry is added or remove (addSettingsNode() / removeSettingsNode()). However
this involves re-writing wpkg.xml as many times as there are packages assigned
to the host. Which means if you have 20 packages assigned wpkg.xml would be
written 20 times. Actually WPKG 0.9 did this and I removed it because I did not
experience problems when it is written just once on proper termination of WPKG
so I left this optimization in. My intention was to operate in memory as much as
possible because especially during bootup the system is already loaded by heavy
disk operations and accessing disk (writing in particular) is always something a
programmer should wisely plan. In general WPKG has been designed to be able to
start from any state and bring the system to the desired/defined state. So even
a crash (no matter in which state) should be recoverable by WPKG.

If it's causing severe problems to lots of you we can change it.


> What do you think about a "Commit" after each successful executed task
> so that WPKG.xml reflects the real status.

See above.


> This could be done automatical or by a flag.

Well, for such an internal thing I would recommend not to use a flag - it's more
confusing than helping - and enabling/disabling internal optimizations should
not be a flag. Either we decide to go for some optimization or we go for some
overhead - both should be reliable. So I would like to hear if and in which
cases people have problems with this feature.


br,
Rainer