http://bugzilla.wpkg.org/show_bug.cgi?id=183
--- Comment #3 from Jason Oster <parasy...@gmail.com> 2010-05-03 22:11:49 CEST --- Created an attachment (id=158) --> (http://bugzilla.wpkg.org/attachment.cgi?id=158) Debug log showing an already-installed-package failing the installation check and performing a "re-install" via the install actions. Rainer, thanks for the detailed response. In fact, I did think this over quite a bit. I've been using the patch for about a year. It has been helpful in my use-case: switching packages revision numbers to use application version numbers in quite a few cases. I use WPKG to control software installations on approximately 100 workstations; none of those allow normal users to install software or upgrade existing software. I've gone as far as disabling automatic updates like those included with Adobe Reader, Java, and even Firefox extensions; WPKG has sole authority over what is installed on any of my systems. I can imagine some WPKG deployments rely on the downgrade feature for actually installing older versions of software, like the name of the command implies. To my knowledge, WPKG will always "do the right thing" in your given example. (Please correct me if I'm wrong, I would love to learn more about WPKG's package processing!) I'll take a deeper look at that now: 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? 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. 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.) 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. 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. 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. 2) The downgrade action was purposefully left off. 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. 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. 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. ;) 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. Thanks! -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. ------------------------------------------------------------------------- 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
