Issue 33449 - OOo needs a constant install directory / folder (Update installation should not use a new directory)
Summary: OOo needs a constant install directory / folder (Update installation should n...
Alias: None
Product: Installation
Classification: Application
Component: ui (show other issues)
Version: OOo 1.1.2
Hardware: All All
: P3 Trivial with 37 votes (vote)
Target Milestone: OOo 3.0
Assignee: Olaf Felka
QA Contact: issues@installation
Keywords: oooqa
: 49405 72560 81800 83097 (view as issue list)
Depends on: 76369 76371
Blocks: 75000
  Show dependency tree
Reported: 2004-08-26 15:24 UTC by markellse
Modified: 2008-04-30 07:40 UTC (History)
8 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description markellse 2004-08-26 15:24:58 UTC
At the moment, each version of OOo installs in a separate directory with a
different name. This is not what most users want. It causes problems with
locations of dictionaries, templates, shortcuts, etc. If you want to keep them
when upgrading from, say 1.1.1 to 1.1.2, you have to put 1.1.2 in a directory
labelled 1.1.1.

What most users want is a single copy of OOo on their machine in a
directory/folder called the same name whatever version it is. So that their
installation stays in the same place, with the same settings, with the same
shortcuts pointing towards it when they upgrade. 

This is particularly true in a coporate environment when upgrading perhaps sever
dozen or more machines.


Mark Ellse
Comment 1 Olaf Felka 2004-08-26 15:39:19 UTC
We have an update feature for OOo, this should be used. This update feature uses
the directory of the previous installed Office.
of @ cj: I think this is something we should discuss for OOo 2.0
Comment 2 fschambe 2004-09-20 16:17:11 UTC
This issue also causes problems if shortcuts are copied as the install program
does not update the path in those shortcuts.
Comment 3 christian.jansen 2005-05-23 09:16:02 UTC
CJ->CP: Please decide.
Comment 4 justinf 2005-05-24 00:00:43 UTC
Since 680_m65+ is feature complete 
this would be suitable addition to the next minor
release 2.1 ? I assume most people would want to
replace their existing copy of 2.0 at its release
Comment 5 markellse 2005-05-26 09:15:15 UTC
Only those developing/testing OOo want different versions. Absolutely Everybody
using OOo simply wants a single, latest version in the same place. This is
really important for large scale deployment. I support OOo on about 100
machines. I know! Cheers
Comment 6 christof.pintaske 2006-02-27 10:15:43 UTC
cp->is: 4you
Comment 7 2006-10-11 11:16:46 UTC
Comment 8 markellse 2006-12-23 16:11:58 UTC
Super to have update on 2.1 BUT it still installs in a new directory. And when
you install it, it doesn't say that it's going to be in a new directory. 

Please, please, can we have a constant install directory, perhaps called
OpenOffice, just like proper programs? 
Comment 9 2007-01-04 14:55:44 UTC
IS -> FL: Sending this task to you, because we need a solution together with
task i72560. At least, user experience has to find a solution for the future OOo
Comment 10 Olaf Felka 2007-01-04 15:07:26 UTC
I think that we should use a constant destination for OOo unless it would be
incompatible somehow e.g. 1.1.x to 2.x.
Comment 11 fschambe 2007-01-04 15:11:35 UTC
OF: That is an acceptable solution, ie, \OpenOffice1 \OpenOffice2 or even adding
a 2.0 and then the subversions would be updates to the major versions within the
appropriate folder. 
Comment 12 markellse 2007-01-04 15:22:38 UTC
I don't really see why the 1.1.x against 2.x should be regarded as incompatible.
An overwrite of 2.x onto a folder with 1.1.x will simply replace what is there.
2.x is backward compatible - it will pick up 1.x templates and documents. There
is no reason why it should not be installed in the same place.

There is another reason for a constant install directory. The file associations
for windows do not all automatically transpose when installing a new version of
OOo at the moment, because the new files are in a new place. And if, like me,
you've made shortcuts with replacement (clearer) icons for OOo, these don't
automatically go to the new program file locations.
Comment 13 Olaf Felka 2007-01-04 15:33:35 UTC
1.x has become incompatible to 2.x because of a new installer: OOo 1.x comes
with his own installer, OOo 2.x uses the system installer. That's why they
should not have used the same destination. This might also happen because
several reasons.
Comment 14 frank.loehmann 2007-01-04 16:48:29 UTC
FL: I think a OOo/SO folder without a version number would be the best solution.
We should check if we are on risk if we do so. We definitely should drop the
behavior to put the minor numbers in the program folder's name.
On installing a new version/update we should rename the old folder first, then
do the installation and remove the old folder afterwards. This would allow us to
do a new installation without changing the folder's name. Furthermore this
allows us to abort the installation process and rename the old application
folder again, if the user presses cancel during the installation.
Comment 15 Olaf Felka 2007-01-05 09:11:39 UTC
That's not how the MSI is working. First it uninstalls the old version and then
it installs the new version. I think that the renanming action fl suggested is
much to risky. Having an OOo destination folder without versioning would be the
best solution if possible. We are facing the same problem with the user layer.
Comment 16 kpalagin 2007-05-06 10:05:03 UTC
Dear developers,
issue seems to be dup 
of  this one.
Please choose which one should be closed.
Comment 17 kpalagin 2007-05-06 10:38:15 UTC
*** Issue 72560 has been marked as a duplicate of this issue. ***
Comment 18 kpalagin 2007-05-06 10:38:32 UTC
Copying CC, dependencies, blocks and target from Issue 72560
Comment 19 kpalagin 2007-05-06 15:49:42 UTC
*** Issue 49405 has been marked as a duplicate of this issue. ***
Comment 20 2007-05-14 14:03:03 UTC
IS -> FL: After closing i72560, this will be the task, in which you can
discuss/decide the name of the install directory.
Comment 21 frank.loehmann 2007-09-07 10:29:42 UTC
Set target to OOo 3.0.
Comment 22 Olaf Felka 2007-09-21 10:04:40 UTC
*** Issue 81800 has been marked as a duplicate of this issue. ***
Comment 23 meywer 2007-10-01 16:33:36 UTC
OO2.3 again installs (rpm) to a path openoffice.org2.3 beside openoffice.org2.2
and then deletes the folder openoffice.org2.2 without to ask about this. 
I think it should ask.

Main problem is the change in the path, because links (e.g. on desktop) don't
work no more.

I wonder that file-type-preferences in kde, krusader, ... are updated - this is
better than formerly, when they were „killed“.

Comment 24 meywer 2007-10-01 20:54:45 UTC
> I wonder that file-type-preferences in kde, krusader, ... are updated - 
> this is better than formerly, when they were „killed“.

At least it worked for odt- and sxw-files. 
For ods I had to tune manually.
Unfortunately even by using kcontrol I'm not able to tell krusader it shall open
xls,rtf,doc-files with swriter ‒ really strange. It still says „KDEInit kann 
/opt/openoffice.org2.2/program/swriter nicht starten.“.

Comment 25 Olaf Felka 2007-10-29 19:44:24 UTC
*** Issue 83097 has been marked as a duplicate of this issue. ***
Comment 26 kpalagin 2008-03-02 14:16:25 UTC
Are we on track for 3.0 with this issue?
Comment 27 iknowjoseph 2008-04-08 12:31:31 UTC
Last night I updated 130-ish users from 2.3 to 2.4; those users who had created
their own shortcuts clicked on them this morning and accused me of having
removed OO.o from their machines.

I registered here simply so I could vote on this issue.

I'm hoping that all 3.X releases install to a standard OO3 folder.
Comment 28 frank.loehmann 2008-04-29 08:35:28 UTC
FL->OF: It seems that this issues has been addressed during re-packaging of OOo.
Comment 29 frank.loehmann 2008-04-29 08:42:12 UTC
Comment 30 markellse 2008-04-29 10:39:43 UTC
Please, please, let's not have a directory for OOo 3 which says OOo3. Please
let's have a directory that stays the same whatever version of OOo is used. The
directory simply needs to be called OpenOffice. We don't want fuss when OOo
changes from 3 to 4. Let's hit this problem forever. Thanks.
Comment 31 Olaf Felka 2008-04-29 10:55:53 UTC
I don't think it makes sense not to have the major release number in in the
target directory. It might come to incompatibilities between OOo 3.x and a
upcoming 4.x. To prevent those problems it would be better to separate the
target directories.
Comment 32 markellse 2008-04-29 16:19:54 UTC
Sorry to push about this, but I really don't think that those who suggest
keeping a version number on the program folder really understand the problems of
administering OOo on a large number of machines. Just changing file associations
on a hundred machines is a real pain. I know, I have to do it.
Microsoft manage to keep Word in the same place irrespective of versions. 
Is the OOo development team is unable to do this - a technical 'can't do'? 
Or is it 'We can do it this time, but we want to keep options open in future'?
Or 'We can't really see why you are fussing about this so much?'
Comment 33 eugene_saenko 2008-04-30 07:06:00 UTC
I think when new wersion is incompatible with previous the setup program have to
ask me what I prefer -- clean up existing directory for new installation or
create new directory for installation. In such case I can decide what kind of
headache is less painful for me.
Comment 34 Olaf Felka 2008-04-30 07:37:48 UTC
Cleaning up a directory is a good idea. But which version should make this? The
uninstallation of an 'old' OOo version can't do this: If you have installed
extension that are shared for all users, the files are left in the office
folder. The new version shouldn't do this because it's data loss. And so it
might come to incompatibilities. But back to this issue: The summary says
"Update installation should not use a new directory". So we are talking about an
update from e.g. OOo 3.a.b to 3.b.a. This problem is fixed with OOo 3. The
installation target directory for the OOo executables is now 'OpenOffice.org3'.
And that's why the issue is fixed. Everything else should be a new issue and be
discussed in the developer mailing list ( or better in the
User Experience mailing list (
Comment 35 Olaf Felka 2008-04-30 07:39:06 UTC
This is the behavior of the developer snapshots of OOo 3.x.
Comment 36 Olaf Felka 2008-04-30 07:40:16 UTC
therefor closed