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

[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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jason_oster.vcf
Type: text/x-vcard
Size: 304 bytes
Desc: not available
URL: <http://lists.wpkg.org/pipermail/wpkg-users/attachments/20100503/7a6bd1c6/attachment-0002.vcf>