Issue 33449

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

This issue also causes problems if shortcuts are copied as the install program
does not update the path in those shortcuts.

CJ->CP: Please decide.

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

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

cp->is: 4you

Accepted

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? 

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

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.

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. 

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.

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.

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.

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.

Dear developers,
issue http://qa.openoffice.org/issues/show_bug.cgi?id=72560 seems to be dup 
of  this one.
Please choose which one should be closed.

*** Issue 72560 has been marked as a duplicate of this issue. ***

Copying CC, dependencies, blocks and target from Issue 72560

*** Issue 49405 has been marked as a duplicate of this issue. ***

IS -> FL: After closing i72560, this will be the task, in which you can
discuss/decide the name of the install directory.

Set target to OOo 3.0.

*** Issue 81800 has been marked as a duplicate of this issue. ***

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

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

*** Issue 83097 has been marked as a duplicate of this issue. ***

Are we on track for 3.0 with this issue?

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.

FL->OF: It seems that this issues has been addressed during re-packaging of OOo.

Fixed.

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.

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.

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?'

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.

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 (dev@openoffice.org) or better in the
User Experience mailing list (discuss@ux.openoffice.org).

This is the behavior of the developer snapshots of OOo 3.x.

therefor closed