Hi, On 03.05.2010 22:12, bugzilla-dae...@bugzilla.wpkg.org wrote: > Where user's upgrade their own software: > 1) A package for, say, Firefox 3.5 has been installed by WPKG. > 2) User installs Firefox 3.6 over top of 3.5; WPKG still thinks 3.5 is > installed. > 3) The next time WPKG runs, it will note the discrepancy (install checks > fail); > wpkg.xml currently has 3.5, and packages.xml (on the server) is the same. > What > does it do in this case?
This depends on the checks. But actually there are only two possible ways to go for WPKG. First possibility: The checks are still true. E.g. you check for an uninstall entry with a regex of "Firefox.*". In this case WPKG will not perform anything since it still thinks the Firefox version supposed to be installed is still there. Second possibility: The checks are not true any more. E.g. your check for uninstall entry with a regex of "Firefox 3.5" does not match any more. In this case WPKG will have to perform the install command since according to checks WPKG has to assume the package is not installed at all. In advance WPKG allows the possibility to define checks for versions in uninstall and file entries. Typically my packages use the "versiongreaterorequal" check which in this case would allow Firefox 3.5 or newer to be installed. So it would still detect the package to be installed correctly in your example. If the admin is now going to update the package it will perform the upgrade commands defined in the package. > It cannot perform a "downgrade" action, because the revision number on the > server-side package hasn't been reduced. For this same reason, it also cannot > perform the upgrade action (the revision number on the server has not > increased). In my tests, it actually performs the install action in this case > ... where (installed package revision == server package revision) && install > checks fail. Correct. WPKG detects upgrades/downgrades always on package revision attribute changes. Not on presumably changed software versions installed. And no, you cannot use checks to make WPKG detect the current version and depending on the version installed either execute upgrade/downgrade or install commands. Hmm, actually a nice thought, but would probably require much more development and also much more changes to WPKG. In fact the checks would have to change from being simple "current-state" checks to some sort of version checks (new sort of checks). It would work with version comparison checks (like file version or registry uninstall version values) only. But it would allow WPKG to detect whether the currently installed version is newer or older than the one supposed to be installed. Maybe it would also be helpful regarding another request sent to the list recently about performing the package checks before actually performing an upgrade to check if the user eventually already upgraded to the desired version (so no update needs to be performed). Unfortunately "managed" updates are pretty often not only checking that the latest version is installed but also making sure that policies and some settings are correctly deployed. So quite often it's desired that in case of a managed update (update pushed by system admin) the package is entirely installed no matter if the user already performed a manual upgrade or not. Just to make sure a trusted version of the application is installed along with the policies and modules expected rather than an installation fetched from any internet location and performed by the user in a custom mode. I am not sure yet if this would be a good thing because first of all such a feature would heavily depend on the quality of the version comparison algorithm and it would be impossible or very complex to define rules/commands for specific version ranges (e.g. upgrading Firefox 2.x to 3.0 might require another procedure than upgrading 3.0 to 3.5...). In any case it's a good hint and I will think about it. > The worst that will happen is failing to install the software (due to a number > of reasons, typically because a newer version is already installed, as you > mention. Otherwise, the re-install will succeed, and the user's "upgrade" > gets > overwritten. Keep in mind, this is how WPKG works *right now*, without the > patch. I'm attaching a debug log that shows this in action. (I've stripped > the useless lines of the log, and marked the most important with asterisks.) If users are allowed to install their own upgrades an error during any upgrade is much more likely to happen than in managed environments without user permissions to perform custom upgrades. The reason is not that WPKG performs the wrong commands but simply that you cannot take into account every modification which might have been performed by the users. For example a user might install an update into a custom folder and therefore no matter how detailed your upgrade/downgrade/install commands are it might fail. Most software package install well if the installer is just re-run in silent mode. Just overwriting whatever is currently installed. In fact in most environments this is even desired behavior since after the admin released an official version of a software he wants the users to use exactly this version. For example I've experienced admins to allowing users local software installations (well, giving local admin rights you cannot prevent it). So users installed Firefox 3.6.3 while the official Firefox release for the company was 3.6. So users could upgrade "at their own risk" to 3.6.3. Some did. Later the admin decided to release Firefox 3.6.2 (and not 3.6.3) since it was tested and worked with all corporate applications. The result was that the rollout just leveled all installations to 3.6.2. Sure you can claim that some users have been downgraded, but hey, they did the upgrade on their own risk, they are allowed to upgrade to 3.6.3 again and sure, these are the users complaining about incompatibilities with corporate applications. > Second, I want to be clear that I'm not suggesting that WPKG should treat > upgrade and downgrade as "the same thing". I believe that really would break > the way WPKG currently does its thing. Rather, I just want a sane fall-back > when WPKG wants to downgrade but it can't, because it is missing any downgrade > actions to perform. And here that's the point I do not agree. Most of the time I do not put downgrade commands on purpose. I want WPKG to stop here and to report such issues. But probably it's a slight misunderstanding as well. WPKG will only perform a downgrade if you decrease the package revision number. Not if you increase the number but the installed software is already newer. E.g. if you roll out Firefox 3.6.0 (package revision 2) and the user runs Firefox 3.6.3 (self-upgraded, package revision 1 locally installed, package initially supplied Firefox 3.5) WPKG will perform the upgrade commands due to the fact that the package revision is increased. So as I wrote above WPKG would require an entirely new type of checks in order to detect the _current_ version installed in order to decide whether upgrade/downgrade commands have to be run depending on the version actually installed and the version number to be deployed. Nice thought but might be tricky to implement. WPKG was initially not even supporting version comparison checks on uninstall or file base and was working entirely on package revision only: - revision increases: upgrade - revision decreased: downgrade (hmm, not even sure when the downgrade was introduced, probably it was me at a later stage) So this could be a feature for WPKG 2 to support a special check which allow WPKG to decide whether it has to perform an upgrade, a downgrade or nothing at all. I will think about it but it's off topic here. > The only case, that I am aware(!), where a downgrade action will run is in the > event that a package with a "large" revision number is first successfully > installed (and saved in wpkg.xml) and at some time later, the package is > modified with a "smaller" revision number AND there is a downgrade action > specified. Exactly, because WPKG works based on package revision only. Upgrade/downgrade decision is not taking into account any checks, it's just decided on the package revision number. > I cannot dream up all possible situations where an admin would end up with > this > result, but it seems to me the most common two would be: > > 1) The downgrade action was simply forgotten. Currently unlikely since as I said, the admin would have to specify a lower package revision on purpose. If you're lowering the package revision (I did it a couple of times) it usually has one purpose: The revision you rolled out previously is faulty or does not work as expected. Therefore you downgrade your clients. Quite often the same can be achieved by preparing an appropriate upgrade command and increase the package revision, so the upgrade following will perform the rollback/downgrade of the software. > 2) The downgrade action was purposefully left off. This is the case which happened to me more often. I did a mistake in the package revision field and WPKG immediately reported that it performs a downgrade - without any negative effect since I did not intend to do any downgrade and therefore did not specify any command. > In the former case, the correct action is to fail. (And in this respect, you > are absolute right!) But in the latter, *something* is expected to happen. Why? The purpose of NOT specifying any downgrade command is also to prevent WPKG do to anything in case of unexpected downgrade detection. You just assume that if I do not specify any downgrade command I still have in mind to do a downgrade once. But the purpose of not specifying a command can also be to prevent WPKG to run anything in this case. > IMHO, the benefits of leaving off the downgrade action (falling back to an > upgrade action) outweigh the possibility of someone forgetting the action and > having the package fail; it could still fail (albeit maybe breaking the > software installation in the process) or it could actually succeed anyway, > doing what was intended in the first place. On top of that, an additional > benefit is simplification of the packages database by not duplicating all of > the upgrade actions to downgrade actions. WPKG executing some commands you did not clearly intend to run (by running commands you did not specify) could also leave your systems in a state which is unexpected and even difficult to recover. So I disagree that the benefits outweight the failure potential. Just saving you 30 seconds of properly specifying downgrade commands does not outweight the potential of having to run to all my >100 machines to fix the package state. > On that last point, I have one package with 18 upgrade commands (ugh, Java... > Although it could be worse: http://wpkg.org/Java ) If I can save myself > maintaining duplicate upgrade/downgrade actions at the risk of possibly > botching a very small handful of my packages during the testing phase, I'm > perfectly fine with that. You might not be surprised to know that I end up > botching those in hundreds of other ways already. ;) Oh oh, some people on the list will not like this answer. Why don't you simplify this upgrade commands (18+) and push them into a simple batch script? So simply call this script during upgrade AND during downgrade, simple copy of one line in XML. Again I am coming back to the proposal to ask a GUI developer to do this for you. A simple checkbox in WPKGExpress could solve the problem for you without endangering people which do not know it better. Inserting a checkbox like "[x] use upgrade commands for downgrade" would do the job while it makes it perfectly simple to administrate, explains the purpose and still allows people to remove the tickmark and leave it up to the admin whether he wants to specify any custom downgrade commands or just do not specify any downgrade commands on purpose. This way WPKG itself offers full flexibility and also offers admins to decide whether they like to specify downgrade commands or not. Having WPKG selecting downgrade commands itself just does not allow admins any more not to specify any downgrade commands on purpose. > Finally, I'm relieved to hear that this (or something like it) has been > discussed before. I haven't seen the discussion yet, but now that I know it's > out there somewhere, I will have to find it and catch up on the popular > opinion. It may be a topic worth reviving. That's why we are discussing about it here. However my perspective is clear. This is a feature which can be provided by a sophisticated interface (like a GUI). But the discussion brought some additional idea to my mind, so future versions of WPKG probably provide a functionality to detect upgrade/downgrade/install decision based on special checks. Thanks Rainer ------------------------------------------------------------------------- wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/ _______________________________________________ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users