Created attachment 47833 [details]
screenshot of the upgrade that wasn't
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.
#rpm -e $(rpm -qa | grep -i -E "^libobasis|libreoffice")
Then do a reinstall with "rpm ivh"
Please make the upgrade an actual upgrade.
We're currently on 3.4.4, have you still got this issue ?
(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
Great ! So I put this tracker to RESOLVED/WORKSFORME (in this case for you :-))
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.
(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.
(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.
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.
Todd, is this bug here still an issue with new versions of LO?
(In reply to comment #7)
> Todd, is this bug here still an issue with new versions of LO?
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.
4.1 to 4.2 did not upgrade either. Both are now installed and I have to do a manual removal of 4.1.
(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?
Petr: one for you?
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.
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).
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
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
(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
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.
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
@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 ;)
(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 ;)
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.
(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.
The bug tracker is not on our infrastructure so we have almost no control - we are currently trying to migrate to our own but it's quite a bit of work. If you have some spare cycles to help with anything (not just bug tracker migration) please send me a private email - our teams are stretched really really thin.
P.S. This is still an enhancement request ;) PPA's work different than manual installs and this is expected/planned/desired.
and - this would be the right email to email me to ;) Apologies was just doing bug cleanup and had logged into admin account :)
I am a bit confused by the comment #18.
AFAIK, only the minor releases are installed in parallel on Linux. For example 220.127.116.11 is installed in parallel with 18.104.22.168. 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, 22.214.171.124 should replace 126.96.36.199 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.
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?
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 188.8.131.52 to 184.108.40.206. It does not update 220.127.116.11 to 18.104.22.168 because the package names are different and rpm tool does not know that they are related.
(In reply to comment #22)
> BTW: I wonder what Linux distribution the customers use
I get them from here:
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-22.214.171.124-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.
(In reply to comment #24)
> Note that "rpm -U" currently updates the package only of the same minor
> version, e.g 126.96.36.199 to 188.8.131.52. It does not update 184.108.40.206 to 220.127.116.11
> 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.
Okay, now this is embarrassing. I posted the following over on Red Hat for LibreCAD:
$ su root -c "rpm -Uvh LibreOffice_18.104.22.168_Linux_x86-64_rpm/RPMS/*.rpm"
error: Failed dependencies:
libobasis4.3-en-US <= 22.214.171.124-2 is needed by (installed) libobasis4.3-en-US-help-126.96.36.199-2.x86_64
But it is not missing:
$ rpm -qa libobasis4.3-en-US
That sure look "<= 188.8.131.52-2" to me.
And they answered me (what a bunch of nice guys)!
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
You're updating from a directory full of rpms for LibreOffice
184.108.40.206. What the error is saying is that in the transaction,
libobasis4.3-en-US gets updated from 220.127.116.11 to 18.104.22.168, but
libobasis4.3-en-US-help does not, leaving it with an unresolved
dependency on the old libobasis4.2-en-US (22.214.171.124), 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 126.96.36.199, 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?
But I'm betting that package is still there and just didn't get downloaded into your directory for some reason.
Hope that helps.
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/).
(In reply to Todd from comment #27)
> Okay, now this is embarrassing. I posted the following over on Red Hat for
And I did it again! My last post was suppose to be for bug "76227" :'( :'( :'(
(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
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?
I put it back to NEW since I've nothing more to suggest now.
(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!
On Ubuntu 16.04, I had LO 188.8.131.52 installed and now installed LO 184.108.40.206 (../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).