Hi Simon, simplesi wrote: > > I've been thinking about WPKGs default behaviour (following from earlier > > discussions) and I'd like to start a genuine discussion on changing its > > current behaviour.
OK, let's try to get a common understanding of the ideas first. > > Currently, WPKG will attempt to remove an existing package from the local > > compuer wpkg.xml file if it decides that an existing package is no longer > > referenced for that computer, regardless of the lack on any remove cmd in > > the package. That's true. If a package was assigned to a host before (the only way they go to wpkg.xml) and then removed by administrator then WPKG assumes the package should be removed from the host. The definition in profiles.xml (package assignment) defines the supposed state of the client and wpkg.xml represents the current/actual state of the client. Comparing them allows us and WPKG to find out what has to be modified to reach the state supposed. > > I believe that it would be better if it didn't and that it should only > > remove a package from wpkg,xml if it decides that the package no longer > > applies and there is a remove cmd in the package. OK, let's first be sure that I understand this correctly. The first part means that WPKG should remove the entry from wpkg.xml (as it is now) but only when the special condition "at least one remove command is defined" is true. This means that in case you do not specify any remove commands the package would remain win wpkg.xml even if the administrator removed it from hosts.xml. This has a couple of other effects too. Let's summarize some of them I could imagine: A positive effect would probably be that an administrator could see from wpkg.xml that the package has been assigned once on the system. However by keeping profile.xml histories this would be possible too. A negative effect would be that after a while there might be pretty much packages in wpkg.xml where no remove command is specified and where there is no corresponding package on server side. Currently this would lead to a couple of errors because of the "zombie" state of this package. Zombie state means that the administrator does not have any control over this package any more (removed from packages.xml). Another drawback in most installations would be that wpkg.xml files are not comparable easily any more between systems. Some of them might have additional packages which have been applied once and then removed before applying to all nodes - so they remain in wpkg.xml on some nodes and not in others. It could also become an issue in terms of WPKG execution-performance. Remember that WPKG will have to verify all packages locally installed. This means it would have to verify all these on each synchronization too just to find out that they should be removed and due to this special rule (no remove commands) its removal is skipped. This way of handling packages also introduces some question what would happen in case a package with no removal commands is broken. For example if Office was applied to a system without remove commands and then the package is deleted from the server. It remains on the client and the checks are executed on each synchronization. As long as it's installed it might be fine - but what if the checks fail (somebody uninstalled office)? Either it can be ignored (since removed by admin anyway) leaving orphaned entries in wpkg.xml which are completely ignored. Or it could be re-installed (which might fail if Office is removed from the server share). Or it could remove wpkg.xml entry then but this renders the only advantage (keeping history of installed packages) useless. > > Also, the current default behaviour of attempting and upgrade before > > attempting a removal doesn't feel to me to be the best way of dealing with a > > faulty remove cmd as I think it is not a logical action to take. Well in theory it's a bit "special" but for me and many others it seem to work properly and was helpful in many cases. The administrator only needs to take care that the latest package version is perfectly in shape and removes properly. So an admin does not have to worry about what would happen when he removes the package from a profile because he has in mind that some old versions he forgot about the remove commands and if a PC was not updated for a while the removal would fail on next run. In addition you're free to switch off the upgrade-before-remove behavior - but surely you know because it has been implemented on your request. > > I can understand that it allows for multiple attempts to get the removal > > right but I think that if a removal has gone wrong, it would be better to > > write a new "hunter-seeker" :) package to correct the error. These "multiple attempts" should be done on test systems. But there might be cases machines in production behave differently - so fixes to the package might be required sometimes (not only fixes to the deployed software). I think in most cases a "hunter-seeker" package is less convenient to users. Just imagine your situation above. You have a package where you did not specify any remove commands and then decide to remove it from the profile. As a system administrator I would expect the software to be removed - with the suggested change the package remains on the system and I need to create such a "hunter-seeker" package. And how should this work now? Should this "hunter-seeker" package have install-commands which remove the second software? Which checks do you define for the "hunter-seeker" package? How is the "hunter-seeker" package handled and uninstalled itself? > > I don't think having lots of different flags is the way forward and it would > > be better to reach consensus :) I agree that the number of flags should be kept small. However currently WPKG just needs a few. In basic installations you can use 'cscript wpkg.js /synchronize' and that's it. All other settings can be put to config.xml. Remember that the /noUpgradeBeforeRemove was just introduced on request of you while I don't think anybody except you is using it yet. But I accepted that your use case required it. Well, I apologize that I probably did not fully get all your ideas. I kindly ask you to give us some more insight on your use-case. If possible make a few examples where your use-case will be in place and why you can't do that with the current implementation. I can always try to allow you a bit more flexibility but it's difficult or impossible to implement conflicting requirements. I would like to get different opinions on your request too - let people express if they think it could be helpful or not. I will try to explain possible side-effects or drawbacks then as I did above. You might try to implement some of your ideas too and then send it for public review/test to see if existing users are satisfied with your proposals and if their way of using it is compliant to the changes suggested. br, Rainer PS. Sorry Simon for sending it twice - I hit the wrong reply button. Now copied to the list too. ------------------------------------------------------------------------- wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/ _______________________________________________ wpkg-users mailing list [email protected] http://lists.wpkg.org/mailman/listinfo/wpkg-users
