Bug 38171 - During Install Ask if Install "in Parallel" or "Upgrade"
Summary: During Install Ask if Install "in Parallel" or "Upgrade"
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
3.4.0 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Installer
  Show dependency treegraph
 
Reported: 2011-06-10 16:34 UTC by Todd
Modified: 2018-12-20 13:35 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot of the upgrade that wasn't (94.05 KB, image/png)
2011-06-10 16:34 UTC, Todd
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Todd 2011-06-10 16:34:19 UTC
Created attachment 47833 [details]
screenshot of the upgrade that wasn't

Hi All,

I just attempted to upgrade 3.3.2 to 3.4.0 with "rpm -Uvh *.rpm" from "..LibO_3.4.0rc2_Linux_x86_install-rpm_en-US/RPMS".  It did not upgrade, but rather made a parallel install in a separate directory.  

Workaround:
#rpm -e $(rpm -qa | grep -i -E "^libobasis|libreoffice")

Then do a reinstall with "rpm ivh"

Please make the upgrade an actual upgrade.

Many thanks,
-T
Comment 1 Julien Nabet 2011-11-29 12:32:58 UTC
We're currently on 3.4.4, have you still got this issue ?
Comment 2 Todd 2011-11-29 16:02:26 UTC
(In reply to comment #1)
> We're currently on 3.4.4, have you still got this issue ?

3.4.3 upgraded with "-Uvh" perfectly to 3.4.4.

The problem was 3.3.2 to 3.4.x.  "Rpm -Uvh" treated 3.3.2 and 3.4.x as two separate programs
Comment 3 Julien Nabet 2011-11-29 22:47:43 UTC
Great ! So I put this tracker to RESOLVED/WORKSFORME (in this case for you :-))
Comment 4 Todd 2011-11-30 10:12:00 UTC
No.  Actually, it does not work for me.  The problem was 3.3.2 to 3.4.x.  You are basing your assessment on upgrading from 3.4.x to 3.4.x+1.

Only close this if the 3.3.x branch is defunct and no one will be upgrading from it to 3.4.x.

To do so, by the way, requires a complete uninstall of 3.3.x and a fresh new install of 3.4.x.
Comment 5 Julien Nabet 2011-11-30 10:31:45 UTC
(In reply to comment #4)
> No.  Actually, it does not work for me.  The problem was 3.3.2 to 3.4.x.  You
> are basing your assessment on upgrading from 3.4.x to 3.4.x+1.
> 
> Only close this if the 3.3.x branch is defunct and no one will be upgrading
> from it to 3.4.x.
According to the release plan (http://wiki.documentfoundation.org/ReleasePlan#3.3_release), there won't be another 3.3.x version.

> 
> To do so, by the way, requires a complete uninstall of 3.3.x and a fresh new
> install of 3.4.x.
Ok but I think it's because the way to manage the profile is different between 3.3.x and 3.4.x. I haven't succeeded in finding the thread about this on dev mailing list :-(

I let you judge if this case can be closed or not.
Comment 6 Todd 2011-12-01 20:11:51 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > No.  Actually, it does not work for me.  The problem was 3.3.2 to 3.4.x.  You
> > are basing your assessment on upgrading from 3.4.x to 3.4.x+1.
> > 
> > Only close this if the 3.3.x branch is defunct and no one will be upgrading
> > from it to 3.4.x.
> According to the release plan
> (http://wiki.documentfoundation.org/ReleasePlan#3.3_release), there won't be
> another 3.3.x version.
> 
> > 
> > To do so, by the way, requires a complete uninstall of 3.3.x and a fresh new
> > install of 3.4.x.
> Ok but I think it's because the way to manage the profile is different between
> 3.3.x and 3.4.x. I haven't succeeded in finding the thread about this on dev
> mailing list :-(
> 
> I let you judge if this case can be closed or not.

Hi Julien,

   What I would like to see accomplished is the "rpm -Uvh" function to work on the next big upgrade.  In other words, when 3.5.x hits, the "-U" (upgrade function) will upgrade 3.4.x to 3.5.x automatically.  And not require a full uninstall of 3.4.x before installing 3.5.x.  The upgrade needs to seamless and not require I.T. to accomplish it.

-T
Comment 7 retired 2013-09-01 11:55:33 UTC
Todd, is this bug here still an issue with new versions of LO?
Comment 8 Todd 2013-09-01 20:02:09 UTC
(In reply to comment #7)
> Todd, is this bug here still an issue with new versions of LO?

Hi James,

Upgrading from 4.0.x to 4.1.x was a nightmare.  All of the 4.0.x programs/files were left behind and 4.0.x was fully functional alongside 4.1.x.  I had to do a full removal of both packages, no easy feat, and then reinstall 4.1.x.

-T
Comment 9 Todd 2014-01-31 23:36:09 UTC
4.1 to 4.2 did not upgrade either.  Both are now installed and I have to do a manual removal of 4.1.
Comment 10 Todd 2014-01-31 23:45:17 UTC
(In reply to comment #9)
> 4.1 to 4.2 did not upgrade either.  Both are now installed and I have to do
> a manual removal of 4.1.

Guys!  This truly is a pain in the neck.  Would you please fix this soon?

Many thanks,
-T
Comment 11 Julien Nabet 2014-02-01 08:17:13 UTC
Petr: one for you?
Comment 12 Petr Mladek 2014-02-03 09:35:11 UTC
The current solution is intentional. LO uses time base release process, see https://wiki.documentfoundation.org/ReleasePlan#Summary. It means  that the early releases might include pretty annoying bugs. It is very handy to have installed two LO versions in parallel. The last version with new lovely features and some older stable version as a fallback. In fact, many Windows users have dreamed about this behavior for a long time.

It is true that the current Linux behavior is primary useful for QA guys and early adopters. More conservative users would want to just update. Well, IMHO, these conservative users often use the stable and better integrated version that is provided by their Linux vendor. They do not use the slightly limited universal build.

I would close this bug as NOTABUG. But life moved my focus to other areas and I do not longer actively work on LO. I do not feel comfortable to do decision affection that many users. So I keep this bug open and just add a developer and a QA guy to CC.
Comment 13 Todd 2014-02-03 17:14:44 UTC
Peter,

This is a pain in the neck.  If you want two versions kicking around, use "rpm -ivh" for "install" (install a new copy).

If you want to "upgrade", and only have one copy kicking around, "rpm -Uvh" is what to use.

And since when does LO not get better with each release.  I have never come across a regression.  LO, unlike OO actually fixes their bugs.  (Well, LO can't print an envelope for its life. Those bugs aren't getting fixed, but they are not regressions.  They don't get worse with each release -- they just stay the same.)

Please come up with a method that has the option to leave dual version installed for those who want such things (developers, etc.), or removed the old trash and just upgrades (users).

Many thanks,
-T
Comment 14 Joel Madero 2014-02-26 00:37:48 UTC
Yes this is NOTABUG and as planned - it has lots of benefits and apparently annoying for a single user but in general it is very beneficial. Users can purge their install before installing the new one easy enough. Over 2.5 years and really only one user has ever raised this
Comment 15 Joel Madero 2014-02-26 01:16:17 UTC
The more I think about this the more I think it's a valid enhancement request. Updating and marking as NEW - I think this addresses the concern and could potentially be useful.

That being said it's an enhancement request and possibly quite hard to implement so might not be done any time soon
Comment 16 Todd 2014-02-26 18:25:48 UTC
(In reply to comment #15)
> The more I think about this the more I think it's a valid enhancement
> request. Updating and marking as NEW - I think this addresses the concern
> and could potentially be useful.
> 
> That being said it's an enhancement request and possibly quite hard to
> implement so might not be done any time soon

Hi Joel,

I am a Linux consultant.  I know that I have several installs when my custom icons bring up the old version.  Your standard user, using standard icons won't know this.  Their hard drives will eventually fill up with the stuff and they won't know why.  Kind of like a time bomb.  So it is really not a issue that only one user (me) complained about this if standard users have no way of telling.  It should be addressed before disaster strikes.

Changing this to "enhancement" works for me.

-T

If it helps, the following are my notes on removal ("#" is root's bash command line prompt):

RPM Removal of Libre Office:

# rpm -e $(rpm -qa | grep -i -E "^libobasis|libreoffice")

Once removed, goto to /opt and remove the old version's directory
Comment 17 Joel Madero 2014-02-26 18:45:14 UTC
@Todd - while I completely understand - we make it pretty clear that our "standard user" should not be using a x.x.0 release - this only occurs when you do because we purposely like to easily be able to run releases in parallel for many reasons -- also many users who do choose to use a "fresh" release (ie. x.x.0 and x.x.1 would want to run in parallel to ensure they still have their stable release installed. If you stick to the repositories and ppa's (which is what we suggest to essentially everyone) then you'll never face this problem.

But - I have never seen any chatter about this on mailing lists, or on our bug tracker - I'd suspect that if it's a wide running problem that multiple people have said something by now as our users are more than happy to report when they notice issues ;)
Comment 18 Todd 2014-02-26 19:12:37 UTC
(In reply to comment #17)
> @Todd - while I completely understand - we make it pretty clear that our
> "standard user" should not be using a x.x.0 release - this only occurs when
> you do because we purposely like to easily be able to run releases in
> parallel for many reasons -- also many users who do choose to use a "fresh"
> release (ie. x.x.0 and x.x.1 would want to run in parallel to ensure they
> still have their stable release installed. If you stick to the repositories
> and ppa's (which is what we suggest to essentially everyone) then you'll
> never face this problem.
> 
> But - I have never seen any chatter about this on mailing lists, or on our
> bug tracker - I'd suspect that if it's a wide running problem that multiple
> people have said something by now as our users are more than happy to report
> when they notice issues ;)

Hi Joel,

I get an eMail notification from you guys as to a new release and I install it.
You fix a ton of bugs (EXCEPT ENVELOPE BUGS), so a new release is always met with bit of joy.  (A software project that "actually" fixes bugs -- who would have though.)

I download from your standard download page.  (My customer use both the Linux 64 bit and Windows versions so I carry them both on flash drive to install when I see them.)  So I am sticking with the "repositories".  If these are meant to remove prior versions as you implied ("you'll never face this problem"), then we should move this back to a "bug" and not an enhancement.

My complaint was not with x.x.0 upgrades, which you actually do upgrade, it is with the x.0.0 and 0.0.0 upgrades.  3 to 4 was a real pain in the neck.

As far as "chatter", be glad I caught it before your user's hard drive fill up.  Everyone's /opt directories will thank you.

-T
Comment 19 Todd 2014-02-26 19:27:27 UTC
(In reply to comment #18)
"who would have though" should be "who would have thought"

"My customer" should be "My customers".  I have a lot more than one.

Has anyone request an "Edit" function for the bug tracker?  No matter how much I proof read, I miss a lot of stuff, that is, until I press "save changes".  Then they all show up.

:'(
Comment 20 QA Administrators 2014-02-26 19:33:38 UTC Comment hidden (no-value)
Comment 21 Joel Madero 2014-02-26 19:34:23 UTC Comment hidden (no-value)
Comment 22 Petr Mladek 2014-02-27 09:24:34 UTC
I am a bit confused by the comment #18.

AFAIK, only the minor releases are installed in parallel on Linux. For example 4.1.0.4 is installed in parallel with 4.0.5.2. By other words, LO 4.1 is installed in parallel with LO 4.0.

On the other hand, any bugfix release replaces an older release of the same minor version. For example, 4.1.1.2 should replace 4.1.0.4 on Linux. By other words, an LO 4.1 bugifx release replaces any older 4.1 release.

This is caused by the fact that the package names include the minor version, e.g. libobasis4.1-writer.
Also the menu entries include the minor version, e.g. 4.1.


BTW: I wonder what Linux distribution the customers use and why they could not use the LibreOffice packages provided by the given Linux distribution. It would most likely solve the problems with updates. Also the distribution specific builds might have more features, e.g. KDE4 integration.
Comment 23 Joel Madero 2014-02-27 14:40:26 UTC
Petr - I pointed out something similar. It sounds like the original reporter wants all users to have "latest and greatest" as soon as it comes out and that users who want the latest and greatest don't know how to uninstall things in Linux - I disagree with this (for two reasons) but still valid as enhancement yes?
Comment 24 Petr Mladek 2014-02-27 15:31:44 UTC
Hint: One possibility would be to remove the version from the package names but keep them in the filenames. Then people could install more versions in parallel using "rpm -i" and update to the latest version using "rpm -U".

Note that "rpm -U" currently updates the package only of the same minor version, e.g 4.1.0.4 to 4.1.1.2. It does not update 4.1.0.4 to 4.2.0.4 because the package names are different and rpm tool does not know that they are related.
Comment 25 Todd 2014-02-27 18:18:27 UTC
(In reply to comment #22)

> BTW: I wonder what Linux distribution the customers use

Hi Petr,

I get them from here:
http://www.libreoffice.org/download
After I get an announcement in my eMail.  I am not using "nightlies" or GIT or test anything.

> and why they could not use the LibreOffice packages provided by the given
> Linux distribution.

Because I am on Scientific Linux 6.5, with is a Red Hat Enterprise Linux 6.5 clone.  As such, it is purposefully so, very, very out-of-date.  And, since most of my customers are using Windows, I need to have the same version they have so I can support them properly.  (A lot of the bugs I report come from my Windows customers.)

# yum whatprovides libreoffice
...
1:libreoffice-4.0.4.2-9.el6.x86_64 : Free Software Productivity Suite
Repo        : sl6x

Surprised they are not on "3" still.  They are still on Firefox 24, meaning no TLS 1.2 support


> It would most likely solve the problems with updates. 

I think this enhancement request would do a better job.

> Also the distribution
> specific builds might have more features, e.g. KDE4 integration.

Actually, I need the generic version so that I can support my Windows customers.

-T
Comment 26 Todd 2014-02-27 18:21:32 UTC
(In reply to comment #24)

> Note that "rpm -U" currently updates the package only of the same minor
> version, e.g 4.1.0.4 to 4.1.1.2. It does not update 4.1.0.4 to 4.2.0.4
> because the package names are different and rpm tool does not know that they
> are related.

This what I would like fixed.  Otherwise , your /opt direction grows and grows.  Plus, regular users would have no idea this was happening.

I like the idea of giving the user a choice.  Being able to retain older versions would have benefits to some.
Comment 27 Todd 2014-11-17 21:25:26 UTC
Okay, now this is embarrassing.  I posted the following over on Red Hat for LibreCAD:

https://bugzilla.redhat.com/show_bug.cgi?id=1113380#c5
    $ su root -c "rpm -Uvh LibreOffice_4.3.4.1_Linux_x86-64_rpm/RPMS/*.rpm"
    Password: 

    error: Failed dependencies:
            libobasis4.3-en-US <= 4.3.3.2-2 is needed by (installed) libobasis4.3-en-US-help-4.3.3.2-2.x86_64

    But it is not missing:
          $ rpm -qa libobasis4.3-en-US
          libobasis4.3-en-US-4.3.3.2-2.x86_64

    That sure look "<= 4.3.3.2-2" to me.



And they answered me (what a bunch of nice guys)!

https://bugzilla.redhat.com/show_bug.cgi?id=1113380#c6

     I'm really not sure how you ended up here, this is a closed bug on
     Librecad (not LibreOffice). That said, I'm going to try to guess at
     your issue:

     You're updating from a directory full of rpms for LibreOffice
     4.3.4.1. What the error is saying is that in the transaction,
     libobasis4.3-en-US gets updated from 4.3.3.2 to 4.3.4.1, but
     libobasis4.3-en-US-help does not, leaving it with an unresolved
     dependency on the old libobasis4.2-en-US (4.3.3.2), and failing
     the transaction (because you don't want broken dependencies).

     I would look in that directory and see if libobasis4.3-en-US-help
     is in there, I suspect it is missing. If that package went away
     in 4.3.4.1, it _should_ have been properly Provided/Obsoleted by
     something else in the package set (likely libobasis4.3-en-US),
     but since that clearly isn't happening, you might have to manually
     remove libobasis4.3-en-US-help before trying to update again:

     su root -c "rpm -e libobasis4.3-en-US-help"


Is there something here that will help you guys?

Many thanks,
-T

But I'm betting that package is still there and just didn't get downloaded into your directory for some reason.

Hope that helps.
Comment 28 Julien Nabet 2014-11-17 22:17:48 UTC
Please uninstall any LO rpm package, then clean your rpm directories and try again to download the whole 4.3.4 LO version from official website (see http://www.libreoffice.org/download/libreoffice-fresh/).
Comment 29 Todd 2014-11-18 01:33:29 UTC
(In reply to Todd from comment #27)
> Okay, now this is embarrassing.  I posted the following over on Red Hat for
> LibreCAD:

And I did it again!  My last post was suppose to be for bug "76227"  :'( :'( :'(
Comment 30 Todd 2014-11-18 01:38:08 UTC
(In reply to Julien Nabet from comment #28)
> Please uninstall any LO rpm package, then clean your rpm directories and try
> again to download the whole 4.3.4 LO version from official website (see
> http://www.libreoffice.org/download/libreoffice-fresh/).

This is what I do.  I do a full "rpm -e":
   # rpm --nodeps -e $(rpm -qa | grep -i -E libobasis|^libreoffice\.org|libreoffice")
   # rpm -e $(rpm -qa \*libreoffice\* | grep -i menu)

And I posted to the wrong bug, twice.

I see a NEEDINFO.  Was someone waiting on info from me that I missed?
Comment 31 Julien Nabet 2014-11-18 21:10:56 UTC
I put it back to NEW since I've nothing more to suggest now.
Comment 32 Todd 2016-08-05 00:52:46 UTC
(In reply to Julien Nabet from comment #31)
> I put it back to NEW since I've nothing more to suggest now.

I just got nailed upgrading from 5.1 to 5.2.

This bug is so exasperating!

If the developers what several copy kicking around, they should come up with a way to do that for themselves.  Not torture all their user base with it!
Comment 33 Christian Lehmann 2018-12-20 13:35:42 UTC
On Ubuntu 16.04, I had LO 6.1.3.2 installed and now installed LO 6.1.4.2 (../deb.tar.gz). Without any feedback, the installer installed the new version in parallel, though in a completely different directory: LO 6.1.3 was/is in /usr/lib; LO 6.1.4 is in /opt. Both the installer's decision to do a parallel installation and the choice of the different main directories are anything but self-explanatory for the user.
There are situations where the user wants two parallel versions of LO, and there are other situations where he doesn't. The LO installer should check if an older version is already installed, warn the user accordingly and leave the decision concerning parallel installation or update/upgrade to him.
At this point, there should be an associated help item telling the user about the advantages and disadvantages of either solution. One problem that I experienced is the following: The Unity launcher gets completely confused if two versions of the same software are being used.
If the user decides to update/upgrade, it would be a service to him if the installer could first uninstall the previous version, preserving, however, the user's personal settings (s. bug 122205).