It's not possible (without dirty tricks) to update a 3.3.2 installation of LibreOffice to the 3.4.0beta2, because of unfortunate naming of packages. There are versioned package names, that install files to non-versioned directories. both core as well as extension packages are affected. For example /opt/libreoffice/program/kdefilepicker is in package "libreoffice3.3-core01" and "libreoffice3.4-core01" As both have a different name, the libreoffice3.4-core01 is not considered an update of libreoffice3.3-core01, thus rpm as well as dpkg try to install the 3.4-0beta2 one alongside of the 3.3.2 one, and of course fails because both packages include the same files (the same filepaths) It's a bad idea to have versioned package names when they use a non-versioned directory. The only way to do a clean update in this case is to add tons of "Obsoletes" statements in all affected packages. ######################################################### Two ways to solve this dilemma 1) Allow packages to installed along each other (except the desktop-integration one - you have to decide which version should be in your DE's menu, what should be default for the corresponding mime-types) In this case, make the installation directory versioned as well. /opt/libreoffice3.4/..... for example 2) Have 3.4.0 be an update to previous version(s) In this case remove the version from the package names, and add a corresponding Obsoletes: <packagename>3.3 to the packages (or put a hard break to it without adding Obsoletes-directive and make manual uninstallation of previous versions mandatory for the users by putting it in big letter to the release notes) (note that neither of the above is a replacement for special development versions that can always be inside alongside release(candidate) versions like bug #36437 requests)
*** Bug 36457 has been marked as a duplicate of this bug. ***
This is IMO a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=31747 [Bug 31747 - broken debian files ]
No, 31747 is no duplicate. Only the very last comment is the same problem, but the rest of the problem is about a conflict of en-US vs. en-us. bug #31747 is a mutating issue (turning from problem A in completely different problem B). Dealing with those issues is a pain in the a… and in most cases it's far easier to write a new bug with a clean, focused description, instead of having to read through pages of comments) This issue: Version part of package name, but files in non-versioned directories Other issue: Something about en-US in the package name, but an en-us in the package's dependencies (or the other way round - no idea whether this still applies, I don't use deb).
Steering committee has decided to allow to install LO-3.3 and LO-3.4 in parallel, see http://lists.freedesktop.org/archives/libreoffice/2011-April/011185.html I am going to fix the linux part: * rename libreoffice3 packages to libreoffice3.4 * change the default prefix from /opt/libreoffice to /opt/libreoffice3.4 * keep user configuration in ~/.libreoffice/3 Fridrich, Tor, Thorsten, could you please do something similar on Windows and MAC for LO-3.4.0-rc1 release?
So when the steering committee decided to "allow" a parallel installation, did they mean that this should be *optional*? I.e. that it should be possible for the user to *choose* whether to install 3.4 in parallel with an earlier LO installation, or whether to let it overwrite/override it? That will be quite hard to implement on Windows at least, without actually providing two separate sets of installers for two completely separate products, one which is a new version of the LibreOffice product, one which is a new LibreOffice3.4 product.
(In reply to comment #4) > I am going to fix the linux part: > > * rename libreoffice3 packages to libreoffice3.4 > * change the default prefix from /opt/libreoffice to /opt/libreoffice3.4 Done Note that even the desktop integration packages can be installed installed in parallel. Everything is versioned, including desktop menu entries and the libreoffice3.4 wrapper. There was a long discussion and it is not easy to do this for Windows. Though, we decided to produce non-conflicting daily builds using tinderboxes for Windows (so called dev builds).