Issue 86080 - unopkg: cannot --shared install as sudo'ed root when non-sudo OOo active
Summary: unopkg: cannot --shared install as sudo'ed root when non-sudo OOo active
Status: CLOSED DUPLICATE of issue 79648
Alias: None
Product: udk
Classification: Code
Component: code (show other issues)
Version: OOH680m7
Hardware: All Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: joachim.lingner
QA Contact: issues@udk
Depends on:
Blocks: 90439
  Show dependency tree
Reported: 2008-02-13 19:58 UTC by caolanm
Modified: 2008-06-06 14:11 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

not a serious solution, but a workaround (1.25 KB, patch)
2008-02-14 11:08 UTC, caolanm
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description caolanm 2008-02-13 19:58:51 UTC
So run e.g. writer as a normal user, and try sudo unopkg list --shared

You need to close the already opened Extension Manager to continue.

ERROR: Lock file indicates that a concurrent Office process is running!

unopkg failed.
Comment 1 Mathias_Bauer 2008-02-14 09:59:49 UTC
Jochen, one for you, I assume.
Comment 2 caolanm 2008-02-14 11:08:01 UTC
Created attachment 51509 [details]
not a serious solution, but a workaround
Comment 3 joachim.lingner 2008-02-14 12:14:57 UTC
Please use the -H option of sudo to set a different home.

As for the lock file, one should think of circumventing it in some cases. For
example, when just listing the extensions, there is probably no risk of getting
the extension data in an inconsistent state. That is, the unopkg process is only
reading while the office process could be writing. That could be an enhancement

Comment 4 caolanm 2008-02-14 12:42:58 UTC
sudo -H is not really a solution, just a workaround :-( e.g. some third party
provides .rpms./debs of an OOo extension for RHEL/JDS/Debian and calls unopkg
during e.g. %post. The person installing them has no knowledge that unopkg is
being called on their behalf, nor should they really have to know, so there's no
basis for them to know that *these* rpms/debs cannot safely be installed with
sudo, while all other ones can. 

The other unfortunate side-effect is that if e.g. a sysadm uses sudo to invoke
unopkg when he doesn't have a ~/.openoffice.org2 directory then a
~/.openoffice.org2 will get created for him belonging to root.
Comment 5 caolanm 2008-02-19 11:53:50 UTC
interesting, this was reassigned back to me, that makes no sense
Comment 6 caolanm 2008-02-22 10:38:00 UTC
Just to make it clear, the other effect of this is that if the user doing the
sudo *does not* have a ~/.openoffice.org2 and installs with unopkg --shared a
new package then a ~/.openoffice.org2 will be created belonging to root.
Comment 7 kay.ramme 2008-03-07 15:50:36 UTC
Jochen, please have another look into this ...
Comment 8 joachim.lingner 2008-03-17 10:47:31 UTC
As for the lock file, this is a duplicate (issue 79648). Starting unopkg with a
different use installation is a workaround. Also the post install scripts can
call unopkg with providing the bootstrap variables on the commandline
(-env:UserInstallation ....).

During installation on wouldn't expect that data are written to $HOME. But I do
not share the idea that sudo -H is generally a workaround.

That .openoffice.org2 is created should not surprise, since OOo does the same
when started as root. 

When one wanted to permanently setting the user installation,etc. when using
unopkg --shared,then this should be done for Windows as well. The behavior
should be the same on all platforms.

I would not recommend JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY because it is not
documented in framework.h (issue 87117)

I'm going to set this one to duplicate.

*** This issue has been marked as a duplicate of 79648 ***
Comment 9 joachim.lingner 2008-03-17 10:48:19 UTC
Comment 10 caolanm 2008-03-17 11:23:52 UTC
of course even without a lock file using unopkg with sudo without that user
already having a ~/.openoffice.org2 dir will create a situation that the user
will not be able to launch OOo because his dir belongs to root.
Comment 11 joachim.lingner 2008-03-17 12:58:05 UTC
As I indicated, I would not expect that a program writes into the $HOME during
installation. In all other scenarios, a user should now what a tool does before
using it. It is legitimate that a program writes data into the home dir. When I
use a program as root, then I should not complain that the program acts
accordingly.  And here you are right, the lock file is only one of many files
which may later be inaccessible for the user. So I'll have to think some more
about issue 79648. However, what happens when the user runs sudo soffice? Would
we need to provide soffice also with a --shared switch, so that it can recognize
a case where it must not write to the homedir?

Again, I do not believe that we should workaround the wrong use of sudo (except
maybe during the installation). One could of course ague that if all do it
wrong, it would be good to handle the case. On the other hand, I assume that the
average user uses a graphical installer (or double click the rpms) and only
"experts" use the command line.

Also, thank to the use of bootstrap variables one can easily workaround the
problem in the post install scripts.
Comment 12 nospam4obr 2008-04-23 13:16:12 UTC
Until the underlying issues are resolved, I find the attached patch compelling
as it removes the redundancy of having to do all the necessary in several

Currently there are 2 instances for Linux (install/unsinstall) and 4 for Solaris

Even if we do not want this to happen every time when using --shared, we could
add an extra (script only) argument or an extra wrapper script for packaging
Comment 13 pmladek 2008-06-04 19:55:17 UTC
Just a note. We needed to replace "mktemp -d --tmpdir" with "mktemp -d -t". The
"--temdir" option was not supported by mktemp ,version 1.5 that we had on older
distribution (SLED10).

The modified diff can be found at