Hi Simon, simplesi wrote: > I am trying to stop WPKG removing wpkg.xml entries if there are no remove > instructions in a package And exactly here I don't see where the use-case is which would not break the existing specification/purpose of WPKG. If the entry would stay within wpkg.xml then WPKG will think the package is installed at next synchronization. Accordingly it would try to verify/install/upgrade/remove it again depending on the state of the corresponding server-side package. If you would like to be able to remove packages from the profile without uninstalling anything just do not specify any uninstall command and no check. If you would like to use checks just make sure the install/upgrade commands leaves some traces on the system (reg add ..., or any file will do) which you check and then the remove command just removes this traces leaving the actual application installed. This would make WPKG think the application has been removed correctly without removing the application. However in any case wpkg.xml is clearly used to correspond to the current system state. An attempt to drive WPKG in an inconsitent state (package listed in wpkg.xml but package not assigned and/or not installed) is clearly not intended by any software deployment mechanism (not only WPKG). I also don't think this will make anything more simple. Instead it will create lots of cases where people are just curious about wpkg.xml contents - packages still there which have been removed from the profile since a long time or WPKG taking very long time to process since a huge amount of packages are still listed in wpkg.xml. >> What exactly do you try to achieve by this modification? I was under the >> impression that you might like to have an XML file which includes the >> history >> of installations - don't you? >> > No - just trying to make WPKG simpler :) Again. You've not been able yet to convince me that this will support users in keeping a consistent state while doing anything simpler. However you might be able to provide a simple use-case where such orphaned entries in wpkg.xml would make any sense. The current WPKG implementation would not use this orphaned entries anyway except using them for manual remove or synchronization where WPKG would re-try to remove the package on each run since it's not assigned any more. So I was starting to think about what you would like to use these superfluous wpkg.xml entries for. I could imagine that for a GUI (WPKGExpress?) a "history" XML file as I described in Bug report 175 could make sense in order to display some host history without having to analyze log files. This history is not covered by wpkg.xml since - again - it represents the _current_ system state. So feel free to explain the use case you would like to cover without breaking the existing implementation. Probably I am just not getting what you would like to achieve. Is anybody out there supporting Simon and requesting the same change? If yes, could you probably explain in different words what would be the advantage? "Making WPKG simpler" is not clear enough to me. It could mean to make wpkg.js simpler but actually some complexity is due to some special cases and the current implementation has proven to be quite robust. It could also mean making it simpler to use but I've never heard that somebody expects WPKG not to update wpkg.xml when there IS actually a package removed (even if no real command is executed). In fact I am using this approach (no remove commands) too. As long as I am maintaining the product WPKG takes care. When I remove it WPKG just "forgets" about the package without actually removing anything. But this "forget" of course means that the WPKG internal state (wpkg.xml) is updated. If I would like to keep it I think a new functionality like the proposed "history" could be used instead of parsing log files. Actually wpkkg.xml is an internal construct, not to be used by external applications and the current implementation makes sure it's kept as clean as possible. If you manage to modify wpkg.js to implement your functionality we can run the test suite with it and analyze what changes have been made. If it's incompatible or I have strong believes that it could create trouble you can still use it internally or find more people supporting your approach. A doodle poll could be used to ask people which implementation they prefer. To repeat it again. I am not against your change/change request. Maybe it has advantages but they are not clear to me yet. On the other side it seems to me that these changes are incompatible with the "clean system" approach of WPKG and therefore I am currently not planning to support it. br, Rainer |