Bug 117492 - MSI: When installation fails, ensure not to remove previous installed version
Summary: MSI: When installation fails, ensure not to remove previous installed version
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 124193 (view as bug list)
Depends on:
Blocks: Installer-Windows
  Show dependency treegraph
 
Reported: 2018-05-08 07:47 UTC by Mike Kaganski
Modified: 2020-10-20 11:00 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2018-05-08 07:47:37 UTC
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
Comment 1 V Stuart Foote 2018-05-08 20:04:47 UTC
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.
Comment 2 Mike Kaganski 2018-05-08 21:18:33 UTC
(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.
Comment 3 Kumāra 2018-05-18 07:06:54 UTC
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.
Comment 4 Mike Kaganski 2018-05-18 07:12:17 UTC
(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.
Comment 5 Mike Kaganski 2018-05-30 05:31:36 UTC
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.
Comment 6 Kumāra 2018-07-30 04:28:30 UTC
(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.
Comment 7 Mike Kaganski 2018-09-04 08:20:23 UTC
A tentative patch: https://gerrit.libreoffice.org/59970
Comment 8 Mike Kaganski 2018-09-04 16:35:40 UTC
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.
Comment 9 Kumāra 2018-09-05 03:19:43 UTC
(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.
Comment 10 Mike Kaganski 2019-03-22 08:59:34 UTC
*** Bug 124193 has been marked as a duplicate of this bug. ***
Comment 11 VistaMail1 2019-09-25 16:56:54 UTC
A huge lot of users have this problem.
I suggest a simple interaction on installation with the user as fix.
Comment 12 Mike Kaganski 2019-09-25 16:58:34 UTC
(In reply to VistaMail1 from comment #11)

Please elaborate what is "a simple interaction on installation with the user"?
Comment 13 VistaMail1 2019-09-26 10:13:39 UTC
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.
Comment 14 Mike Kaganski 2019-09-26 10:37:23 UTC
(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".