[wpkg-users] [Bug 183] Downgrade should fall back to Upgrade when no downgrade rules exist

[bugzilla-daemon at bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=183

--- Comment #3 from Jason Oster <parasytic at 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.