[wpkg-users] [Bug 77] Zombie package handling

[bugzilla-daemon at bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=77





--- Comment #2 from Rainer Meier <skybeam at users.sourceforge.net>  2007-10-24 13:44:01 ---
Yes I know diff but in this case I did not have it available on the PC where I
uploaded the changed file. Sorry for that - I will do it when I get some time
for it. However the diff will be quite large since I did reformating and
cleanup as well.

About the changed functionality:
Yes I think you understood it correctly. Your note that this should not happen
is correct - but "should" names it precisely. Please imagine a situation where
a package is completely deleted from the package database (server side). In
such case WPKG uninstalls the package at next synchronize. So far so good.

Now imagine that this package defines one or more uninstall strings (which are
saved within the local wpkg.xml) and one of this strings permanently fails.
This could happen if you use a string like 'msiexec /qn /x{GUID}' where the
GUID string is accidentally wrong.
In such case WPKG will retry uninstall forever at each synchronization without
any possibility to fix that problem. The uninstallation will permanently fail.
The only way to overcome this is to create another package with exactly the
same ID and a higher version number in order to replace the local package
(upgrade). But this requires much more effort:
- First I have to re-create the package (if I already deleted it from the
servers)
- Then I have to create a new "dummy" package with higher version number and
fixed uninstall strings
- Then all clients need to boot and apply this new dummy packages
- Then I need to wait until all updates are done (which is sometimes hard to
track if some machines are just booted occasionally)
- After all upgrades I can finally remove the package and it uninstalls
properly on all machines

On the other side I noticed that WPKG just removes the local wpkg.xml entry in
case I do not specify any uninstall string (which is quite often the case). In
such case no uninstall is doe at all.

So my changes will follow the following algorithm now:
- If a package is removed from profile (but still exists in package database)
WPKG tries to uninstall it. In case it fails it will leave it within wpkg.xml
and tries to uninstall again during next synchronization.

- If a package is removed from the package database (completely deleted from
servers) WPKG tries to uninstall it (since it is not within the profile any
more as well). In case uninstall fails it does not retry but removes it in any
case from wpkg.xml.

Therefore package removal could be done in two steps: Old software is removed
from the profiles. During this period clients might try to uninstall it at each
boot and will fail. After a while the package can be removed from the server
package database. This makes sure that the package entry on clients are removed
in any case which fixes problems with local package database.

Again: The reason to develop this changes was to "self-heal" the local wpkg.xml
in case of permanent failures. For example I just created a new package
AcrobatReader_de and AcrobatReader_de to replace the existing AcrobatReader
package which I had. However the uninstall of the AcrobatReader package did not
work properly when I removed AcrobatReader from the package database. The
replacing AcrobatReader_en package installs the same software but WPKG tried to
uninstall the AcrobatReader package at each Windows boot without even a
possibility to fix it. My changes will self-clean the local wpkg.xml by forcing
removal of XML entry.
For me I treat it perfectly acceptable to lose track of packages which I
removed from the package database.
If I do want to make sure it gets removed by successfully uninstalling it then
I will simply not remove it from the package database but just delete it from
the profile.

To make it clear: My changes will only remove a package from wpkg.xml in case
it does NOT exist any more at all on the server package database (just removing
from the profiles is not enough). So just zombie packages are removed in any
case.

Please note as well that I introduced a new switch: "/noforcedremove"
If it is used this will disable this new behavior and packages will even remain
within wpkg.xml if they are zombies. However this has the major drawback that
this might push clients into an endless uninstall-try-loop at each boot which
is even not detectable from server side. Users will probably complain about
increased system load or slow boot up and this is hard to trace. Therefore I
decided that even keeping the old package on the system is a better way to
handle it.


-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


wpkg-users mailing list
wpkg-users at lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users