Bug 111198 - starting openoffice launches installer every time - not just first time - two errors in ooffice wrapper script
Summary: starting openoffice launches installer every time - not just first time - two...
Alias: None
Product: Fedora
Classification: Fedora
Component: openoffice.org
Version: 1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-11-29 20:40 UTC by Need Real Name
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2004-12-02 13:45:14 UTC

Attachments (Terms of Use)

Description Need Real Name 2003-11-29 20:40:29 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a)
Gecko/20030728 Mozilla Firebird/0.6.1

Description of problem:
0) When staring openoffice.org (with ooffice from terminal or icons on
desktop toolbar or from within nautilus by opening a file) the
installer runs each and every time.  Oddly enough, if one first
deletes the .openoffice OpenOffice... .sversionrc .mime.types .mailcap
.recent-files and such it works ok the first time and then screws up
the second and greater times.  One way I found around this is outlined

1) I changed the string "OpenOffice.org1.1.0" to ".openoffice" in my
${HOME}.sversionrc file so that it reads like this:

OpenOffice.org 1.1.0=file:///home/april/.openoffice

PROBLEM: the office wrapper script expects ${HOME}.sversionrc file to
contain the string/directory ".openoffice",
but it actually contains the string/directory "OpenOffice.org1.1.0".

2) I changed the /usr/bin/ooffice script such that an extra slash is not
included in the OOVERSIONRC and OOHOME variable strings.

Output of diff -Naur:

--- /usr/bin/ooffice    2003-11-29 12:56:53.000000000 -0500
+++ /usr/bin/ooffice.orig.broken        2003-11-03 17:14:53.000000000
@@ -36,8 +36,8 @@


 # grab current language

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. use an openoffice application (oocalc myjunk.xsc) with no
initialization files (i.e. no .openoffice dir or .sversionrc file)
2. try the same again (but in step 1 the
initialization/personalization files were created) - and this time the
installer/setup runs ARG....

Actual Results:  openoffice setup runs

Expected Results:  openoffice application to launch

Additional info:

Comment 1 Warren Togami 2004-02-03 23:31:25 UTC
This happens because the openoffice startup script in FC1 and FC2
misdetects and does not co-exist well when programs like StarOffice7
are listed in ~/.sversionrc.

I'm putting this on my TODO list...

Comment 2 Dan Williams 2004-02-10 20:33:55 UTC
hmm, the existence of an OpenOffice.org1.1.0 in your home directory is
probably the result of earlier bugs in the setup program.  These
should be fixed now fi you blow away your ~/.openoffice directory. 
Red Hat's OOo will always install stuff, when operating correctly, in
~/.openoffice.  If not, there's a problem.  Closing since this should
be fixed.

Comment 3 Warren Togami 2004-03-08 09:06:43 UTC
This is still an ugly issue for StarOffice7 installations, which can
too easily cause the openoffice workstation install thing to start
rather than the office suite.  This is on my personal TODO list to solve.

Comment 5 Dan Williams 2004-03-17 20:37:11 UTC
Warren, what are the exact problems of interop between SO7 and OOo?

Comment 6 Eli 2004-03-30 01:27:35 UTC
This one bit me today.  Grrr. 
rm -rf ~/.openoffice worked for me. 
This is a FC1 system that has been upgraded over time, starting at 
7.3 IIRC. 

Comment 7 jason ball 2004-04-16 03:22:45 UTC
This is occurring for me.  My system was upgraded from Redhat 9 and
previouly had the Ximian version of openoffice installed.  All ximian
rpm's were removed prior to the upgrade.

Removing the .openoffice directory did not resolve the issue.

Patching the oofice script as mentioned earlier in the bug report
resolved the issue.

Comment 8 Caolan McNamara 2004-11-12 15:28:34 UTC
I tried first installing a stock openoffice.org-1.1.3 and ran it and
then afterwards installed and ran the FC3 update 1.1.2-11 rpms and all
was well. Does this problem persist in FC2/FC3 or can it be closed now ?

Comment 9 Caolan McNamara 2004-12-02 13:45:14 UTC
I think this is working fine now with FC2/FC3 updates. If it's still
reproducable somehow let me know how and I'll have another look

Note You need to log in before you can comment on or make changes to this bug.