Issue 86080

Jochen, one for you, I assume.

Created attachment 51509 [details]
not a serious solution, but a workaround

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

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.

interesting, this was reassigned back to me, that makes no sense

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.

Jochen, please have another look into this ...

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 ***

.

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.

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.

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

Currently there are 2 instances for Linux (install/unsinstall) and 4 for Solaris
(install/uninstall/prepatch/postbackout).

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

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 
http://svn.gnome.org/svn/ooo-build/branches/ooo-build-2-4-1/patches/src680/ooo86080.unopkg.bodge.diff