Apache OpenOffice (AOO) Bugzilla – Issue 30340
javaldx creates user installation directory during setup
Last modified: 2005-02-28 12:43:15 UTC
During installation the pkgchk (and soon configimport) tools are invoked via a start script (a copy/link of the soffice start script), in order to set up the proper environment. This includes running the javaldx tool, which then creates a javasettings_<platform>.xml file in the 'user installation'. Alas, during setup there doesn't exist a user installation yet - or if there is one it is not necessary the correct one. In a normal multi-user installation scenario the setup is run as root. Thus the directory and file are created with root access rights. If setup is run from a full (login) root shell, a spurious .OpenOffice.org680 directory is created in /root (or whatever is the $HOME of root). If it is run from a 'su' shell (or via 'sudo'), the directory is created in the interactive user's $HOME. In the last case, the user will subsequently be unable to start OpenOffice.org, as no proper user installation can be created any more. In the other cases the data and file created are still Junk. If a user installation already exists in the given place (e.g. from a different installed development milestone), this may interfere with the existing installation (which a setup certainly should not do). Note: The tools are invoked from a scp procedure in classical setup and from a postinstall script in native installers. The same more generally applies when using pckchk --shared (or soon configimport) as administrator. These tools should not step on $HOME of the login user.
Ingo,Daniel: Any comments?
.
p2->p3: If people use sudo they should be well aware of what they are doing. I think it legitimate that the home directory obtained by osl_getHomeDir (or similar) returns $HOME. As for writing the .StarOffice8 directory. I will try to find a different solution.
I think I am encountering a similar problem -- here is the error I get when I try to run setup or soffice as a regular user. Chmod'ing /user/ to 777 stopped the error, but OpenOffice still doesn't start up. [Robin@localhost Robin]$ /opt/OpenOffice112/setup javaldx: could not create link of name: /opt/OpenOffice112/program/../user/temp/java/a which links to /usr/java/j2re1.4.2_04/bin, symlink error: -1
Amanda, the creation of links will be removed in OO2.0. However, a failing javaldx should not cause the office to fail. Have you tried to start soffice.bin instead of soffice?
That is an unrelated problem. Amanda: If you install as root for all users of the machine, you need to use 'setup -net' or 'install' for installation. You apparently installed using plain 'setup' - so the installed office is only usable for the user who did the install. Please see the SetupGuide.
I will introduce a bootrap variable like JVMFWK_SHARED which will cause the java framework to write and use shared settings. When pkgchk (unopkg) is called with the --shared option then it must set JVMFWK_SHARED as environment variable before javaldx and pkgchck.bin is called. If the bootstrap variable is not set then javaldx creates the user directory.
Unfortunately, that conflicts with the current use of a "share" javasettings_x_x.xml. When there is a javasettings_x_x.xml in config/share/ when a user runs the office, then the share settings are used. However, we want that for each user a JRE is located. The reason is, that on the user's machine a JRE which was selected for the admin during setup is not accessable.
That sounds somewhat broken. Why should each *user* have a separate JVM (unless different users require different features - e.g. wrt accessibility). From what you are saying it sound most likely that this setting should be tied to the machine/host where the office is running. It is a fallacy of our traditional term 'network installation' that multi-host installation has not been separated cleanly from 'multi-user installation'. If multiple users share an office on a single machine, it should be possible (for the machine's admin) to set up a default Java installation for that machine. If users from multiple machines use a single office installation from a file server there can't really be a Java setup on the file server that is valid for all client machines.But tying this to the user is just as invalid: if the same users logs in from different machines at different times she may need a distinct Java setup for each environment. In any case it should be possible for a user who has special requirements to specify these requirements. I am not sure one should really go as far as remembering one Java setup for each user/host combination though. For the current issue this is compounded by the fact that in remote or file-server installs the machine on which the installer is run may not be the one on which the application will eventually be exeuted. We really need to sort out the scenarios that should be supported and specify the desired behavior.
*** Issue 35662 has been marked as a duplicate of this issue. ***
*** Issue 35702 has been marked as a duplicate of this issue. ***
This is a duplicate issue. *** This issue has been marked as a duplicate of 34825 ***