Bug 111198

Summary: starting openoffice launches installer every time - not just first time - two errors in ooffice wrapper script
Product: [Fedora] Fedora Reporter: Need Real Name <crharwell>
Component: openoffice.orgAssignee: Caolan McNamara <caolanm>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 1CC: caolanm, elicarter, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-12-02 13:45:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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
here:

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

.sversionrc:
[Versions]
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
-0500
@@ -36,8 +36,8 @@
 }

 OOVERSION=1.1.0
-OOVERSIONRC="${HOME}.sversionrc"
-OOHOME="${HOME}.openoffice"
+OOVERSIONRC="$HOME/.sversionrc"
+OOHOME="$HOME/.openoffice"

 # grab current language
 lang="$LC_ALL"


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


How reproducible:
Sometimes

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....
3.
    

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