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

Tue May 4 09:10:34 CEST 2010

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

--- Comment #4 from Rainer Meier <r.meier at wpkg.org> 2010-05-04 09:10:10 CEST ---
I am sorry, I did not reply on the bug tracker, but I would like to keep the
discussion here:

Hi,

On 03.05.2010 22:12, bugzilla-daemon at 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

-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.