[email protected] wrote:
The fix is to reset the HOME environment variable to /root if we
are being run with uid of 0 to avoid dbus attempting to write a
file on NFS mounted filesystem, for which it does not have
permissions.
Is this really the right way of handling this? It seems very strange
for a user running an application to end up modifying root's home
directory.
David this is just a hack, if you look at the discussion thread in
the community, its a mess and the simple answer is that apps in Gnome
using gconf at the minute are suffering a range of issues and all
having to find their own custom solutions. The Home dir is being set
jsut for the running PM process, so providing PM is working fine and
there are no other issues we should be fine. This will require more
testing to make sure it all works satisfactorily and has no
unexpected side effects.
So we can put this in, or live without the gconf support if you have
an NFS mounted Home dir :( The other suggestion of using dbus-launch
leaves zombie dbus processes hanging around so this is not a viable
solution.
What about using something in /tmp or /var/tmp (the latter, to my
disappointment, seems to be heavily used by GNOME to store lots of
things! :)
Well we could create a unique tmp dir in /tmp and set HOME to that
(/tmp/<unique_tmp_dir>) so it would be unique for that session, perhaps
better than setting the HOME to /root, at least feels less dangerous :)
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss