[wpkg-users] [Bug 175] Test return value of removeSettingsNode function

[Rainer Meier]

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