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

Tue May 4 09:12:47 CEST 2010

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

--- Comment #5 from Rainer Meier <r.meier at wpkg.org> 2010-05-04 09:12:26 CEST ---
Response by Jason Oster:

Seems you're responding to the mailing list, instead of on the bug itself. 
I'll take my response here, as well.

On 05/03/2010 02:05 PM, Rainer Meier wrote:
> Hi,
>
> On 03.05.2010 22:12, bugzilla-daemon at bugzilla.wpkg.org wrote:

(snip)

> Correct. WPKG detects upgrades/downgrades always on package revision attribute
> changes. Not on presumably changed software versions installed. And no, you

This is exactly what I'm focusing on.

> 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

This idea is way too complex for my simple bug/patch.  ;)  Possibly a feature
worth investigating, but not my focus here.

(snip)

> 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.

I agree.

> 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

Yes, this is exactly the action I expect (and want) WPKG to perform.

> downgraded, but hey, they did the upgrade on their own risk, they are allowed to

This is not what I mean when I say "downgrade".  Any time I've mentioned
"downgrade" in this bug, it was referring to the WPKG "downgrade"
actions/commands/XML nodes/whatever the most suitable name for these.

It's exactly because the package revision and software version numbers have no
correlation that I've made this proposal; Sometimes my packages are copy-pasted
from the WPKG packages wiki, and they use revision numbers like 1, then 2, then
3, and 4...  At some point, I feel it's logical to change that revision number
to a number that "matches" the software's version number.

So I change revision="4" to revision="3.6.3" for Firefox (let's assume, for the
sake of clarity, that the package revision "4" had previously installed Firefox
3.6.2)  As far as WPKG is concerned, this is a "downgrade", so it will look for
downgrade actions.

But here I run into trouble, because I don't have any downgrade actions; I'm
not performing a "software version downgrade" ... I'm performing an "upgrade"
with a package revision that just so happens to be less than the previously
installed version.

It is not WPKG's job to decide if this kind of scenario is what it considers a
"downgrade" or an "upgrade".  But I do think WPKG's job here is to do something
other than telling me, "You have no downgrade actions defined, so I will do
nothing. Sorry!"

You are saying that I should stick with my old revision numbering scheme, and
install Firefox 3.6.3 with revision="5".  :(  Or alternatively, copy-paste all
of my upgrade actions, and rename the "upgrade" tags to "downgrade".  Even
though I am not doing a downgrade.  (Confusing!)

> upgrade to 3.6.3 again and sure, these are the users complaining about
> incompatibilities with corporate applications.

Heh heh.  I have first hand experience with such users.  That's why they cannot
install their own software.  (Going way off tangent here, some of them try to
install software anyway, into their My Documents directory, for example. 
Luckily, this does not affect my managed WPKG, because this "rogue
installation" cannot affect any of the "software installation checks" in any of
my packages; file sizes, uninstall entries in the registry, file versions, etc.
 All of these require admin privileges.  Again, this is exactly what I expect.)

> 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.

That definitely makes sense.  And I don't blame you, and that was what I meant
by "accidentally forgot the downgrade -> fail".

(snip)

> 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)

Yep, again, this is my focus area.  (Ignoring the file version, uninstall
entries, all that.)

>> 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.

Sorry, I kind of feel like I'm going around in circles.  But this is exactly
what I'm focusing on; I just want some action to fall back on when no downgrade
actions are defined.  And maybe it's not the right way to go in the general
case.  If that's so, then you've made your point.

>> 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.

Yes.  And we would also explicitly define a series of downgrade actions. 
Except when we don't want to do a downgrade... we want to upgrade, but change
our revision numbering scheme (in the package).  See above, starting with
"Sometimes my packages are copy-pasted ..."

(snip)

>> 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.

So, this patch would have been beneficial to you?  Even with a mistake in the
revision number, you still wanted to upgrade (and we know this by the missing
"downgrade" actions).

>> 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.

This is the only point of contention, and again, I think you're absolutely
right.  It should fail if missing by accident.  It should do something useful
if missing intentionally.  But WPKG will not be able to decide which it is;
accident, or intent?  The only way to proceed is to answer this question:  Does
it make more sense to fail, or should we try to do something useful?

>> 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.

I wouldn't want that.  But you are testing your packages in a sandbox before
deploying any changes, yeah?  I have only one system which I do all my WPKG
testing on before I actually deploy anything.  It might seem like it only saves
30 seconds, but it also saves the confusion of performing "actual" software
upgrades using WPKG's definition of a "downgrade".

>> 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

That's another possibility, even though that downgrade/upgrade confusion could
result, and the maintenance burden thing comes back into play (I'm sure you've
heard all of the reasons against using batch scripts by now).  I do use batch
scripts (sometimes even VBScripts) to perform some complicated install/upgrade
actions.  But for the most part, I try to keep my packages sanely defined.

> 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"

No, please, not that.

However, a checkbox to "fall-back on upgrade actions when downgrade actions are
missing" sounds great!  I don't even use the GUI, but since this would only be
a boolean in config.xml (defaulting to false, of course), I would even be
willing to implement that in my patch!

> 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.

It still makes sense in my mind to implement a "real upgrade/downgrade
detection" but for my purposes, and Bug 183, making an option to "fail or do
something useful" sounds like that way I want to go with this.

>
> Thanks
> Rainer

And thank you, too!
Jay

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