[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

Reply via email to