I've recently upgraded to OOo 1.0.3-rc1. Launching any of the suite from the launcher produced no results. Launching from the command line yields this error: Gnome session manager detected - session management disabled /usr/bin/oowriter: line 209: /home/timhaughton/.openoffice/1.0.2/soffice: No such file or directory /usr/bin/oowriter: line 209: exec: /home/timhaughton/.openoffice/1.0.2/soffice: cannot execute: No such file or directory Now, the config directory in my home dir is still /home/timhaughton/.openoffice/1.0.2 - but the directory in /opt is for 1.0.3. -rw-r--r-- 1 timhaughton users 5909 Mar 3 06:00 LICENSE -rw-r--r-- 1 timhaughton users 6457 Mar 3 06:00 LICENSE.html -rw-r--r-- 1 timhaughton users 13012 Mar 3 06:00 README -rw-r--r-- 1 timhaughton users 16075 Mar 3 06:00 README.html -rw-r--r-- 1 timhaughton users 427220 Mar 3 20:32 instdb.ins lrwxrwxrwx 1 timhaughton users 38 Mar 3 20:32 setup -> /opt/OpenOffice.org1.0.2/program/setup -rw-r--r-- 1 timhaughton users 57194 Mar 3 20:32 setup.log lrwxrwxrwx 1 timhaughton users 40 Mar 3 20:32 soffice -> /opt/OpenOffice.org1.0.2/program/soffice lrwxrwxrwx 1 timhaughton users 40 Mar 3 20:32 spadmin -> /opt/OpenOffice.org1.0.2/program/soffice drwxr-xr-x 15 timhaughton users 360 Mar 3 20:32 user Manually changing the 3 broken links to point at the corresponding files in the /opt/OpenOffice.org1.0.3/program/ directory solves the problem. But I think that the directory in my home directory should have been upgraded during the update. Cheers
*** Bug 21031 has been marked as a duplicate of this bug. ***
Updates never touch home directories. While openoffice also has a per-user installation process, this doesn't touch applnk files. What I suggest you to do look at /usr/share/applnk/OpenOffice.org/*.applnk, and in similar to those refer your links to /usr/bin/{ooffice,oodraw,oowriter,....}
Isn't there a way to avoid this problem without going into the home directories? When an OpenOffice upgrade takes place, either remove or rename the previous OpenOffice install, and put in it's place just enough directory structure to contains symlinks to the new version. It's a safe assumption that even if someone wants to keep the older version around as a backup, they don't want the new version to be broken out of the box, so it's better to require a few extra steps to get to the old one (accessing it in a renamed directory) than to the new. Please reopen this. I was the submitter of a bug marked duplicate.
The /usr/bin programs do provide version independent access to the relevant binaries. If there are missing ones, I will add them, but there is no way in which a "skeleton" can be made which is consistent with portage. It appears Whit has been bitten by the ill design of at least the 1.0.1 version. That design has been corrected in newer versions, in which the breakage is corrected for the future.
