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
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
[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
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).