>>>>> Matthias Clasen <matthias.cla...@gmail.com> writes:

        FWIW, I've filed Debian Bug#688932 [1] to track this issue in
        the Debian GLib package.

[1] http://bugs.debian.org/688932

[…]

 > The actual commit is

 > Tue Mar  5 00:38:54 2002  Owen Taylor  <otay...@redhat.com>

 > * glib/gutils.c (g_get_any_init): Where we have getpwuid[_r], use
 >   that in preference to $HOME, and only check $HOME as a fallback if
 >   getpwuid fails.  (#2311)

 > And the detailed analysis leading to this change is in

 > http://mail.gnome.org/archives/gtk-devel-list/2002-March/msg00066.html

        ACK, thanks for the pointer.

 > I don't think anything has changed there, really.

        Unfortunately, this analysis only concerns the change to the
        HOME environment variable (or lack thereof) made by sudo(8),
        su(8), and usermode.  The question of user changing this
        variable manually wasn't considered there.

        The point is that the software is generally made so that the
        system's configuration (/etc) can be overridden by user's
        (HOME), which, in turn, can be overridden by environment
        variables (FOO_WHATEVER) and, finally, command line arguments
        (--whatever=) or interactively (Edit → Preferences → Whatever.)
        This is a reasonable behavior, and though GLib deviates from it
        also for a reason, it really harms the operation of the
        GLib-based software.

        For instance, there's an easy way to let GNU Emacs read
        /net/home/jrh/.emacs (on NFS) upon initialization, instead of
        /home/jrh/.emacs (on local FS), like:

$ HOME=/net/home/jrh emacs 

        Moreover, GNU Bash started under such a Emacs instance will also
        use /net/home/jrh/.bashrc (instead of /home/jrh/.bashrc), and so
        will GNU Wget, or Lynx, and a sheer variety of other tools.

        … But not the bulk of GNOME, which will insist on using
        /home/jrh/.whatever, perhaps leaving the user no way to choose
        otherwise (sans of persuading the local passwd(5) — or the
        site's LDAP — administrator to change his or her account.)

        The other use case is that the user can always temporarily
        revert to the defaults by using a deliberately empty HOME (say,
        while troubleshooting), like:

$ mkdir -- /tmp/empty 
$ HOME=/tmp/empty myapp 

        Likewise, this isn't going to work for the majority of the GNOME
        applications.

        With the proposed change, these applications will behave just as
        the users expect them to.  Furthermore, I believe that the
        concerns raised in 2002-March/msg00066.html would be relieved,
        provided that the ownership of the directory HOME points to be
        checked as suggested.

 > And it is far too late to change the behaviour of this function, a
 > decade later.

        Then, we're still having a whole lot of GLib-based applications
        to file bug against (as it was just suggested in [2]; and where
        such a bug wasn't filed already), which are then to be fixed in
        each of these applications separately.  Is it really the better
        road to go?

        TIA.

[2] news:20120927124400.ga13...@server.brlink.eu
    http://permalink.gmane.org/gmane.linux.debian.devel.general/176994

-- 
FSF associate member #7257

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Reply via email to