Currently RemoveExistingProducts action is scheduled before InstallInitialize. This uninstalls previous versions prior to installing the new, and in this case, any failure in following installation leaves the system without both the new, and the old version of LO [2],[3],[4],[5],[6]. The correct way to fix this is to resequence the RemoveExistingProducts after installing files [1],[7], presumably after InstallFinalize (as mentioned in the MSDN article to be the most efficient placement for it). This needs a simple patch, but an extensive QA testing. [1] https://msdn.microsoft.com/en-us/library/aa371197 [2] https://ask.libreoffice.org/en/question/50586 [3] https://ask.libreoffice.org/en/question/75285 [4] https://ask.libreoffice.org/en/question/82286 [5] https://ask.libreoffice.org/en/question/98504 [6] https://ask.libreoffice.org/en/question/144563 [7] https://stackoverflow.com/questions/8155097
But wouldn't it make the MSI packaging we do more brittle? Currently we validate -> uninstall -> install -> finalize, and change would be validate -> install -> finalize -> uninstall. Current package sequence is good in general and has served us well--with only a "rare" occasion that the MS Installer balks (for what ever reason) for a user. Isn't that good enough, just continue to _do_ the removal without an obligation to roll back a failed install? And to "just run the install again as Administrator" for those that error out. We should not pretend to be a Windows only development project, nor adopt practices geared to programs that are. We already diverge with our Multi-language MSI (and our language strings longer than 254 characters) as in bug 45750. Or the UI_LANGS command line flag bug 54585.
(In reply to V Stuart Foote from comment #1) > But wouldn't it make the MSI packaging we do more brittle? I wouldn't expect it to be more brittle. However, my expectations might be wrong :) > Currently we validate -> uninstall -> install -> finalize, and change would > be validate -> install -> finalize -> uninstall. (or possibly uninstall-finalize; there are a number of possible placements besides the one mentioned in comment 0) > Current package sequence is good in general and has served us well--with > only a "rare" occasion that the MS Installer balks (for what ever reason) > for a user. > > Isn't that good enough, just continue to _do_ the removal without an > obligation to roll back a failed install? > > And to "just run the install again as Administrator" for those that error > out. Well, that's a possibility, too :) > We should not pretend to be a Windows only development project, nor adopt > practices geared to programs that are. Oh. I fail to see how this is relevant here. The current sequence is one of the possibilities listed in the MSDN documentation; and actually I refuse to accept that trying to be more fail-safe == pretend to be Windows-only. > We already diverge with our > Multi-language MSI (and our language strings longer than 254 characters) as > in bug 45750. Or the UI_LANGS command line flag bug 54585. /me thinks that UI_LANGS issue is not about Windows non-compliance. In general, of course, I filed the bug to get feedback, and I'm glad and open to any PoVs, have no strong feelings about both implementing or *not* implementing the change.
Mike, at bug 76131, you mentioned this fix means "no uninstallation would take place, only removal of replaced/obsoleted files". I think this is worth trying. I suppose it should speed up installation too, besides causing users to lose their pinned icons together with their jumplists.
(In reply to Kumāra from comment #3) Thanks for the opinion; I suppose that I'd try that for the 6.2 release cycle (i.e., after 6.1 branch-off ~next week) _provided that there's some incentive in testing that_ from QA/users. Because personally I cannot provide necessary testing.
Another possible gain here is reduced requirements to close external programs during the installation, because the process would presumably touch less files/registry settings, and thus less likely to interfere with other programs that lock resources (fonts, shell extension, etc.) - see also bug 69066. However, that's just a guess, and depends on Windows Installer being smart enough.
(In reply to Mike Kaganski from comment #4) > (In reply to Kumāra from comment #3) > > Thanks for the opinion; I suppose that I'd try that for the 6.2 release > cycle (i.e., after 6.1 branch-off ~next week) _provided that there's some > incentive in testing that_ from QA/users. Because personally I cannot > provide necessary testing. Mike, I'm keen in this development, but was previously unwilling to commit to testing. Now I can, with a spare netbook.
A tentative patch: https://gerrit.libreoffice.org/59970
I'm sorry to say that it's not as simple technically as it seemed initially. The problem here is the components' GUIDs that must stay intact across the versions. Currently, we have the mechanism that generates the same GUIDs for a component only inside one major version (say, 6.1.x.y installers for all x.y), but for 6.2, the GUIDs for the same component would change. I have tried the patch from comment 7 with installers both inside a major version, and across major versions, and while it looks to ~work inside a version (at least, no apparent problems; and it even keeps pinned icons with their jump lists), it absolutely does not across. The technical problem here is clear, and it is solvable, but it needs more work than I'm able to invest ATM; so leaving this here in case someone wants to jump-in.
(In reply to Mike Kaganski from comment #8) > The technical problem here is clear, and it is solvable, but it needs more > work than I'm able to invest ATM; so leaving this here in case someone wants > to jump-in. Thanks for trying, Mike. Hope someone would jump in soon.
*** Bug 124193 has been marked as a duplicate of this bug. ***
A huge lot of users have this problem. I suggest a simple interaction on installation with the user as fix.
(In reply to VistaMail1 from comment #11) Please elaborate what is "a simple interaction on installation with the user"?
I read only one of these links: https://www.tenforums.com/tutorials/79976-open-local-group-policy-editor-windows-10-a.html It is overwhelming! And I am in informatics since decades. How happy may an ordinary office-user be, to do such a configuration? This "workaround" works only for professionals. So my interaction-idea: Why not asking on startup of the installation-process: "Do you want me to save your task-bar-attached files and start-menu configuration into the registry"? And do the entries into the regsitry as the above link suggests.
(In reply to VistaMail1 from comment #13) > I read only one of these links: > https://www.tenforums.com/tutorials/79976-open-local-group-policy-editor- > windows-10-a.html I'm sorry, but where was this workaround proposed, and by whom? and how is it relevant to the issue? > So my interaction-idea: Why not asking on startup of the > installation-process: > "Do you want me to save your task-bar-attached files and start-menu > configuration into the registry"? > > And do the entries into the regsitry as the above link suggests. This issue is not about "task-bar-attached files and start-menu configuration", it's about the problem that errors in the upgrade process after the previous version already was uninstalled leave the system in a state of absent LibreOffice, despite it's claimed that "no changes have been made". And the link you mentioned doesn't tell anything about changes to registry related to "task-bar-attached files and start-menu configuration".