Side by side install of LibO and OOo

users
#21

This is the issue that I brought up in December on the LO dev list:
<http://comments.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/4130>
[Change executable/sh names]
Here we are on 3.4.rc1 and no further down the line.
You'll need to expand some of the posts in that thread to see that I
actually tested by changing the executables names & that works. Sample:
<http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/4360>

So the issue *still* remains that LO uses OOo .exe names. Does the same
in Linux as well:
$ ls /opt/libreoffice3.4/program
about.png oosplash.bin services.rdb soffice.bin unopkg.bin
bootstraprc python setuprc sofficerc versionrc
fundamentalrc redirectrc shell spadmin
intro.png sbase simpress swriter
kdefilepicker scalc smath unoinfo
libnpsoplugin.so sdraw soffice unopkg

When will LO stand on their own and change these?

#22

In news:itrfh0$4be$1@dough.gmane.org,
NoOp <glgxg@sbcglobal.net> typed:

Hi ..,

aqualung wrote (18-06-11 06:12)

It would be nice to have the option of keeping OOo, for
the odd case when something that works in it is broken
in LibreOffice, or when you need OOo installed in order
to provide help to another user who has OOo but not
LibO.

I think that is a fair idea.

The way to do this, I guess, would be to add an option
in LibO's installation, e.g.:

Thanks for your text. Too me, it looks good, though I am
not interested myself at all, since I use parallel
installation all the time :wink: Could be handy for you too:
http://wiki.documentfoundation.org/Installing_in_parallel

This is the issue that I brought up in December on the LO
dev list:
<http://comments.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/4130>
[Change executable/sh names]
Here we are on 3.4.rc1 and no further down the line.
You'll need to expand some of the posts in that thread to
see that I
actually tested by changing the executables names & that
works. Sample:
<http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/4360>

So the issue *still* remains that LO uses OOo .exe names.
Does the same
in Linux as well:
$ ls /opt/libreoffice3.4/program
about.png oosplash.bin services.rdb soffice.bin
unopkg.bin
bootstraprc python setuprc sofficerc
versionrc
fundamentalrc redirectrc shell spadmin
intro.png sbase simpress swriter
kdefilepicker scalc smath unoinfo
libnpsoplugin.so sdraw soffice unopkg

When will LO stand on their own and change these?

I think you've hit the nail on the head there. OOo and LO are now two
different "companies" for want of a better word, and I've never heard of any
coder wanting to use the same names for their code as another program does.
Swriter etc. being common names was an eye opener I'd never thought of, but
that same naming convention has been in place for a long time. I would think
it falls on LO to do a search & destroy on said application names since
they're the newest kids on the block. Maybe it needs to be Lwriter or
something; anything that's unique and unambiguous.
   There should be NO common files, period, IMO, so that OOo and LO can do
whatever they need to do. Just as AMI, MS, WP, et al can all live together
and even be run simultaneiously, so should OOo and LO.
   Personally I don't care and I'm not sure how valid having to install both
is since there are some workarounds that might suffice, but: OTOH, it does
seem like they should install peacefully, whatever the actual reason is for
the problems; it just makes sense.

HTH,

Twayne`

#23

Hi
Being quite new to LibreOffice, when I had problems with running LO & OOo at the same time, in trying to understand the problem, I discovered that its not just that LO uses the same file extensions, is that OOo is encoded within LO files with OOo pathways and file names, riddled would be a better word.

If you use a file viewer such as that within Ztree, you can see when viewing LO configuration files, that so much is OOo names and OOo pathways. So much so, I cannot think how they would not conflict, just look at the LO "registrymodifications.xcu" file (hundred or more OOo's)

What I find strange is that IBM Open Symphony mini suite (based on OOo) also uses a soffice.exe and if you run all three you will find that you have 3 separate soffice.exe's running. Symphony on the other hand does not conflict in anyway that I can find. So it can be done.

My only way out in the end was to deep remove OOo using Revo-Uninstall and just hope that in the future I don't need it !!.

If you want to keep LO as the default, then you need to deep clean both LO & OOo, then re-install LO first, because for some reason OOo does not overwrite LO.

John B
xp pro sp3
LO 3.3.3.1 & 3.4