[wpkg-users] Remove does not start upgrade
Rainer Meier
r.meier at wpkg.org
Fri Nov 14 12:37:55 CET 2008
Hi Marc,
Marc Hennes wrote:
> You described the goal I want to achieve but at the moment I have two GTK+ packages. I wanted to remove the old GTK+ package from the profile and replace it with the new one. Therefore I first tried to remove the old package by starting wpkg.js with /remove flag. And mentioned that the uninstall string is broken. So I increased the revision of the old package, added a bogo upgrade command and corrected the uninstall string.
The upgrade-before-remove action is only executed on package
synchronization. If you invoke the /remove command then there is no
upgrade-before-remove functionality.
So now I have a look at your log file. Unfortunately you did not include
the local settings file (%SystemRoot%\system32\wpkg.xml) so I have to
guess what is inside.
First of all I see tha WPKG is loading two GTK packages:
2008-11-14 11:19:49, DEBUG : Reading XML file:
//financial.com/SG2/WPKG/WPKG/packages/pack-GTK+_2_10.xml
2008-11-14 11:19:49, DEBUG : Reading XML file:
//financial.com/SG2/WPKG/WPKG/packages/pack-GTK+_2_12.xml
Could you please attach them both as well? Did you make sure that both
package have different IDs? pack-GTK+_2_10.xml seems to use "gtk269" ID.
If pack-GTK+_2_12.xml uses the same ID it will overwrite the package
definition within WPKG (ID has to be unique).
I can see as well that you also use packages.xml:
2008-11-14 11:19:48, DEBUG : Successfully loaded XML file:
\\financial.com\SG2\WPKG\WPKG\packages.xml
You should check if any of your xml files contains a (re-)definition
(probably due to copy-paste) of the 'gtk269' package.
>From the following line I can see that the 'gtk269' package still exists:
2008-11-14 11:19:50, DEBUG : Packages file contains 61
packages:|7zip423|access2007|acrobat7|adminpak|acrobat8|acrobat9|flashplayer-test|flashplayer|alcateltapi|alcateltapi6.3|TestHost|o2007cnv|cygwin|eclipse|fcomregsettings|gs852|gsview47|gtk269|gtk+|ibmrn|ie7|java150_12|java150_13|jdk150_11|jre150_11|wse|firefox20|firefox30|thunderbird107|mysqlodbc35112|dotnet1.1|notepad4|ocstask|office2003|office2007|ooo20|OOo3|paintdotnet|pidgin|pimphony|pimphony6.3|quicktimealternative|ocs-remove|runocs|reutersexcellink|rm6|roxio|test_reboot|gimp228|tortoise1818|visio2007pro|visio2007std|vs2005|vmrcplus|vmwareplayer|vncviewer|wininstaller|wireshark|wpkg-update|wpkg-folder-remove|xmllite-KB915865
This seems to be correct - but I have to admit that the DEBUG output
does not show me which version the 'gtk269' package uses. It also reads
a package called 'gtk+' which might be the one defined in
'pack-GTK+_2_12.xml'.
And hmm, now I miss some synchronization output. So to me it looks
really like you're invoking 'wpkg.js /remove...' and not synchronization.
Again, WPKG is not doing the upgrade-before-remove action on /remove
command (which is supposed to do an immediate remove) but it only
executes upgrade-before-remove if you use the /synchronize option.
So the way to go for you here is to use synchronization which makes sure
the system gets exactly the packages assigned within the profile.
If you do not use synchronization then you need to perform the /upgrade
action on the package manually. Well, I am thinking about now if it
would be a good idea to have WPKG doing the same upgrade-on-remove
functionality on /remove action as well. But I came to the conclusion
that it does not make sense. An administrator who is manually doing
upgrades (if he is not using synchornization) would most probably like
to take full control on each install/upgrade and is therefore not
willing/expecting an upgrade when issuing the /remove command. Such an
administrator would also know quite well (like you) that a specific
package needs to be upgraded before it can be removed and could
therefore initiate the upgrade manually.
So if you want to have full manual control on install/upgrade remove I
think such implicit actions are not a good idea. But most administrators
will use the /synchronize functionality where it makes perfect sense to
assure the package is on the latest revision before removing it.
So please go for automatic synchronization or treat your package with a
special /upgrade action in order to fix it.
By the way: Mixing /synchronize with manual intervention (like manual
/remove or /install) is not recommended as WPKG will try to keep the
system in-synch when using /synchronize and manual interventions will in
any case bring the system out-of-synch with the assigned profile.
So I suggest you to just remove your 'gtk269' package from the profile
and re-run synchronization. Then WPKG will recognize that
- 'gtk269' is outdated => upgrade
- 'gtk269' is not part of the profile any more => uninstall
br,
Rainer
More information about the wpkg-users
mailing list