http://bugzilla.wpkg.org/show_bug.cgi?id=97 Rainer Meier <skybeam at users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |INVALID --- Comment #5 from Rainer Meier <skybeam at users.sourceforge.net> 2008-02-16 19:24:14 --- Oh, you're right - I misinterpreted this fact completely. The reason was that I was simply not sure if in uninstall case where a reboot takes place wpkg.xml is written properly before the reboot. When I checked the code I found that it should handle it properly already. Well, you're right - if the installer/uninstaller is initiating the reboot itself, then WPKG cannot save the XML files and then exactly what I described will take place: => WPKG will do the upgrade-before-remove procedure for all packages again (which re-installs all the packages) Unfortunately I don't see a possibility for WPKG to prevent this reboot initiated by the child process (uninstaller). So my advise is the following: Fix your package on the server (adding the /NOREBOOT flag) and increase the version number. You might even use no upgrade command so the package will actually just update the local package information (uninstall string) while keeping everything as it is. Here the point where the new upgrade-before-remove procedure will ease your life is reached. Now WPKG will first update the WinSCP package (update local package information with your new command-line which contains /NOREBOOT) and immediately remove it afterwards using the correct string. Please report if this works for you. Meanwhile I set this report to INVALID since it's not a bug of WPKG but a fault in the WinSCP package you're using. Furthermore WPKG offers you the possibility to fix the broken package and uninstall it in one single-step by just fixing the package on server side (see above). Please note: Do not forget to increase the package version on the server since the update will not take place if the version is not incremented. Please report if this solution is acceptable for you. The only possibility to avoid this would be to write a new wpkg.xml after each remove instruction executed. Old versions of WPKG (<0.9) were doing this as far as I remember. As this behavior is not really clean software design from my point of view (wpkg.xml is re-written far too often) I implemented WPKG in a way that all run-time data is kept in memory until proper termination. Of course this can be broken by a child command which somehow interrupts WPKG. So I would prefer not to implement a work-around like "writing wpkg.xml several times during execution" just for broken packages. Packages are under control of the system administrator and can be fixed (see above). -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. |