Bug 92245 - Extensions installed for All Users are lost when upgrading to 6.0
Summary: Extensions installed for All Users are lost when upgrading to 6.0
Status: RESOLVED DUPLICATE of bug 62303
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
5.0.0.1 rc
Hardware: Other Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2015-06-22 10:20 UTC by Pedro
Modified: 2017-10-23 07:54 UTC (History)
7 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 Pedro 2015-06-22 10:20:51 UTC
Under Windows XP x86 AND Windows 7 x64 when version 5.0 is installed over a previous 4.x installation with Extensions installed for All Users, the link to the extensions is lost.

Even if the Uninstaller fails to remove the %ProgramFiles\LibreOffice 4\ and sub folders (as already reported) the new link to the extensions is lost.

I believe this is a Major breaker especially for companies where additional extensions are installed for All Users.
Comment 1 Cor Nouws 2015-06-22 14:02:04 UTC
Hi Pedro,

Wasn't this the case in all previous upgrades too?

Cheers - Cor
Comment 2 Pedro 2015-06-22 14:27:48 UTC
(In reply to Cor Nouws from comment #1)
> Wasn't this the case in all previous upgrades too?

There are always leftovers after every major upgrade (from 3.6 to 4.0) but I would have to check if the same happened with extensions.

The devs only worried about not changing the profile name (sticking with "4") but the install folder name is also a problem (at least under Windows...)
Comment 3 Cor Nouws 2015-06-22 15:12:03 UTC
(In reply to Pedro from comment #2)
> (In reply to Cor Nouws from comment #1)
> > Wasn't this the case in all previous upgrades too?
> 
> There are always leftovers after every major upgrade (from 3.6 to 4.0) but I
> would have to check if the same happened with extensions.

It would surprise me if adding again wasn't needed in the previous versions.

> The devs only worried about not changing the profile name (sticking with
> "4") but the install folder name is also a problem (at least under
> Windows...)

I think there is a bunch of partly unpredictable problems that you will face when installing a new version in the same location as an old one and try to reuse whatever..
Comment 4 Buovjaga 2015-06-26 14:18:51 UTC
(In reply to Cor Nouws from comment #1)
> Wasn't this the case in all previous upgrades too?

Never had this problem on Windows.
Comment 5 Michael Meeks 2015-07-03 15:56:11 UTC
Any thoughts Stephan ? and/or is there anything we can do ? =) Thanks Pedro.
Comment 6 Stephan Bergmann 2015-07-06 06:47:40 UTC
I guess the default LO installation path on Windows contains the major LO version number ("4" vs. "5"), but not the minor/micro?

Anybody remember how we handled that from LO 3 to 4?  Like Cor, I tend to remember that we never migrated shared extensions across different installation paths, but may be wrong.

One option might be to copy or move during installation any existing shared extension data from the old to the new installation, but that would need checking that there are no absolute paths stored in that data.
Comment 7 Pedro 2015-07-06 10:53:05 UTC
(In reply to Stephan Bergmann from comment #6)
> I guess the default LO installation path on Windows contains the major LO
> version number ("4" vs. "5"), but not the minor/micro?

Yes, thankfully bug #62303 was partially solved (https://bugs.documentfoundation.org/show_bug.cgi?id=62303#c7)

If enhancement request https://bugs.documentfoundation.org/show_bug.cgi?id=62303 was accepted then this issue would also be solved for the future (in fact this is the expected installation procedure under Windows).
 
> Anybody remember how we handled that from LO 3 to 4?  Like Cor, I tend to
> remember that we never migrated shared extensions across different
> installation paths, but may be wrong.

You are correct. The problem was not solved and assumed it would be on the next major update.
http://nabble.documentfoundation.org/Install-path-for-LibreOffice-under-Windows-td4041530.html#a4043609

> One option might be to copy or move during installation any existing shared
> extension data from the old to the new installation, but that would need
> checking that there are no absolute paths stored in that data.

Or simply update the install path to \LibreOffice\, warn users that extensions installed for all users will be lost and should be installed again and hopefully this would be the last time this problem occurs...
Comment 8 tommy27 2016-12-08 08:33:48 UTC
hi Pedro,
would you please give us an update about this issue?
are you still facing this kind of bug when doing latest 5.1.x and 5.2.x upgrades?
once you answer set it back to UNCONFIRMED if issue is still present or WORKSFORME if it's gone
Comment 9 Pedro 2016-12-08 10:15:44 UTC
Hi Tommy

> would you please give us an update about this issue?
> are you still facing this kind of bug when doing latest 5.1.x and 5.2.x
> upgrades?
> once you answer set it back to UNCONFIRMED if issue is still present or
> WORKSFORME if it's gone

As mentioned in the previous comments this can only be confirmed when version 6.0 is released (it only affects changes in major version)

But I suspect nothing has changed since: 1) the install folder contains a number; 2) the paths have not changed (profile name was even kept at 4)

Solving this kind of problems requires long term planning. LibreOffice is about release fast, release often...
Comment 10 Justin L 2017-05-11 17:59:24 UTC
Marking as "new" since I can confirm that LO 5.x installs to %Program Files%\Libreoffice 5\ on Windows.
Comment 11 Stephan Bergmann 2017-10-23 07:54:54 UTC

*** This bug has been marked as a duplicate of bug 62303 ***