On 05/03/2010 02:05 PM, Rainer Meier wrote:
Hi, On 03.05.2010 22:12, bugzilla-dae...@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
<<attachment: jason_oster.vcf>>
------------------------------------------------------------------------- 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
