[wpkg-users] [Bug 183] Downgrade should fall back to Upgrade when no downgrade rules exist
http://bugzilla.wpkg.org/show_bug.cgi?id=183 Rainer Meier changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #6 from Rainer Meier --- Closing this issue since the outcome is summarized in Bug 184 (command inheritance). -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - 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
Re: [wpkg-users] [Bug 183] Downgrade should fall back to Upgrade when no downgrade rules exist
> > > > Just one thing that might still behave in a controllable way: > > > > > > > > > > > > ---snip > > I think I am going to implement it. > > Would you mind adding it to Bugzilla as an enhancement > request so it's not "lost > on the list"? I could do it myself but I prefer the "sponsor" > of the idea to do it. > > Thanks for the proposal, > > Rainer > Hi Rainer, Sure I will be glad to add an enhancement request to the tracker. --- Stefan - 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
Re: [wpkg-users] [Bug 183] Downgrade should fall back to Upgrade when no downgrade rules exist
Hi Stefan, On 04.05.2010 14:38, Pendl Stefan wrote: > Hi all, > > Just one thing that might still behave in a controllable way: > > > > > > > This way one only needs define the common tasks once and can place them at > the appropriate position before, after or in between the up-/downgrade > command sequence. I pretty much like this idea as well and it could satisfy all needs. It is allowing anybody to "refer" to a group of commands without having to duplicate them. In addition it does not break anything existing since the inherit attribute is new and if no upgrade command is specified WPKG would still do what is expected: Nothing. I think I am going to implement it. Would you mind adding it to Bugzilla as an enhancement request so it's not "lost on the list"? I could do it myself but I prefer the "sponsor" of the idea to do it. Thanks for the proposal, Rainer - 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
Re: [wpkg-users] [Bug 183] Downgrade should fall back to Upgrade when no downgrade rules exist
On 05/04/2010 08:13 AM, heiko.hel...@horiba.com wrote: > > > > > I love this idea - this would save lots of copy/paste and "s/ It seems like a very interesting proposal! (And cutting down on maintenance burden is a *big win*.) In fact, the only "problem" I can think of with this solution is that I'll be adding: To all of my packages. (I wonder if XSLT can help this case? Templates really are perfect for this kind of "boilerplate" that you really shouldn't have to manage everywhere.) The inherit attribute should be the easy part, though. <>- 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
Re: [wpkg-users] [Bug 183] Downgrade should fall back to Upgrade when no downgrade rules exist
Hello List > > > > > > I love this idea - this would save lots of copy/paste and "s/- 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
Re: [wpkg-users] [Bug 183] Downgrade should fall back to Upgrade when no downgrade rules exist
Hi all, Just one thing that might still behave in a controllable way: This way one only needs define the common tasks once and can place them at the appropriate position before, after or in between the up-/downgrade command sequence. About Java, I have managed to reduce the complexity of most of my packages by using the variable definition capability of WPKG and the command prompt. Example: >> << Adding the inherit attribute would reduce the upgrade to one single line, which would be nice to have too. --- Stefan - 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
Re: [wpkg-users] [Bug 183] Downgrade should fall back to Upgrade when no downgrade rules exist
Hello Rainer, Jason, list :) let me attach my opinion to this discussion. > > 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!" I think, in this case wpkg should just decrement the revision number, if the checks are true - and there really shouldn't be downgrade commands, if nothing has to be done but changing the revision number. > > 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!) But: when you're decreasing the revision number in e.g. the firefox package, and you know that there is a possibility that some of your PCs have an older revision (to take your example: installed is 3.5.9, package has revision 4, you insert revision="3.6.3"), why not just specify downgrade cmds identical to upgrade commands, and all is fine? *[OT]* the following is perhaps a bit off topic Anyway, firefox is a special case here, and I'm deploying firefox with extensions for quite some time now. For Firefox 3.6.x, I created a new profile/package and use a new, much easier way for the extensions, see wpkg.org wiki at http://wpkg.org/Firefox#Firefox_Extension_Templates. I expected to have some users/pcs which cannot use 3.6.x for some reason, so the only thing I have to do is assigning "firefox35" or "firefox36" profile to the host to change this. Now, what happens, when I like to downgrade assigning "firefox35" instead of "firefox36": firefox-extension(s) are removed, firefox36 is removed, firefox35 is installed, firefox35-extensions are installed (the old way). Other way round, upgrading after assigning "firefox36" to the host: firefox35-extensions are removed, firefox35 is removed, firefox36 is installed, firefox36-extensions are ok. Best regards, Falko - 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
[wpkg-users] [Bug 183] Downgrade should fall back to Upgrade when no downgrade rules exist
http://bugzilla.wpkg.org/show_bug.cgi?id=183 --- Comment #5 from Rainer Meier 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-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 f
[wpkg-users] [Bug 183] Downgrade should fall back to Upgrade when no downgrade rules exist
http://bugzilla.wpkg.org/show_bug.cgi?id=183 --- Comment #4 from Rainer Meier 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-dae...@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 acco
Re: [wpkg-users] [Bug 183] Downgrade should fall back to Upgrade when no downgrade rules exist
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-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 t
Re: [wpkg-users] [Bug 183] Downgrade should fall back to Upgrade when no downgrade rules exist
Hi, On 03.05.2010 22:12, bugzilla-dae...@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
[wpkg-users] [Bug 183] Downgrade should fall back to Upgrade when no downgrade rules exist
http://bugzilla.wpkg.org/show_bug.cgi?id=183 --- Comment #3 from Jason Oster 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. -
[wpkg-users] [Bug 183] Downgrade should fall back to Upgrade when no downgrade rules exist
http://bugzilla.wpkg.org/show_bug.cgi?id=183 Rainer Meier changed: What|Removed |Added Status|NEW |RESOLVED CC||r.me...@wpkg.org Resolution||WONTFIX --- Comment #2 from Rainer Meier 2010-05-03 20:55:42 CEST --- Either this has been discussed in bugtracker or on mailing list or I had it in mind already and I was just arguing with myself whether to implement such a thing or not. Unfortunately the end of the story was quite clear. Such a "magic" automatic selection of commands (user clearly did not specify any downgrade/upgrade commands but WPKG just selects some commands on its own) would be very dangerous. A lot of existing packages would behave wrongly since upgrade and downgrade are clearly some independent and unrelated things. I agree that for some software packages upgrade and downgrade commands are identical. But for most software I know it's not. Downgrade rather requires removing and re-installing. Sure somebody might argue that in his case all applications use the same downgrade procedure as upgrade procedure. If WPKG would automatically generate commands it's clearly doing something unexpected which can cause problems. I know users (in the office I work for) where users sometimes upgrade applications by themselves. WPKG detects this and would perform a downgrade, but since there are no downgrade commands it's just reported that the software is not identical to what is expected on the system. Such setups would simply not be possible if WPKG would automatically run some upgrade commands in this case. So if such a "feature" would be implemented it would clearly disallow a perfectly valid use case (not specifying any downgrade commands on purpose). Stating that somebody could in this case just specify a "noop" downgrade command which does nothing is not valid since it would require all users (the bigger part of WPKG users presumably) to change their packages to prevent WPKG doing something which they anyway never asked it to do. I would rather vote for a different solution. If you're using WPKGExpress or any other GUI it could be an enhancement request to such a GUI to offer a checkbox to use the same command for upgrade and downgrade while it creates the necessary XML structure in the background. Alternatively it could propose the upgrade commands when specifying the downgrade commands. If you're not using any GUI how much time does the copy of one line XML take you? So please try to think about the "big picture" and you will realize that such a feature would break existing packages and enforce sysadmins to think about this special feature for each package they build. Instead of behaving the expected way (do not execute downgrade commands if none are specified) it would just run commands which were never specified. I perfectly agree that changing this behavior is very simple since WPKG can easily check if there are some downgrade commands and if the list is empty it fetches upgrade commands. Probably a three-liner. But I do not agree breaking the behavior for existing WPKG users just for a "convenience" functionality of some sysadmins which might not have thought about the consequences which can be much worse in some cases if WPKG just runs some commands instead of just doing what it has been told to. Feel free to keep your patch and provide it to others - or refer to this report to get fetch it. I also thought about a switch to enable/disable this behavior, it might be an attribute of the package but I think it's quite useless. If somebody can think about setting an attribute which allows downgrade/upgrade commands to be substituted one could also simply copy the commands in XML. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - 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
[wpkg-users] [Bug 183] Downgrade should fall back to Upgrade when no downgrade rules exist
http://bugzilla.wpkg.org/show_bug.cgi?id=183 Jason Oster changed: What|Removed |Added CC||parasy...@gmail.com --- Comment #1 from Jason Oster 2010-05-03 18:08:10 CEST --- Correction to comment #0: "In this case, I would like wpkg.js to fall back to an *upgrade* command, when no downgrade commands are available." -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - 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
