Re: ${HOME} vs. g_get_home_dir ()
>>>>> Simon McVittie <smcv@debian.org> writes:
>>>>> On 26/09/12 17:12, Ivan Shmakov wrote:
>> (Want to use the all-defaults configuration for a program? Just
>> start it like: $ HOME="$(mktemp -dt -- foo.XXXXXXXX)" foo)
> Debian's GLib has been patched, and actually has this precedence:
> G_HOME > getpwent > HOME. This was originally intended for running
> things like regression tests on buildds, where the HOME specified in
> /etc/passwd typically doesn't exist or can't be written; so G_HOME
> gets set in debian/rules to force the issue.
ACK, thanks for the hint!
[…]
>> I believe that this behavior is buggy. There's even a (yet
>> unresolved) bug report [2] against Gimp due to this behavior
> To be more precise, that bug report is that the man page contradicts
> what actually happens. The maintainer appears to think the correct
> solution is to fix the man page.
If he didn't change his mind over the past four years, that is.
>> To address the only concern listed in [1] I deem valid, I'm also
>> asking that the value of HOME be disregarded, unless it points to a
>> directory, which is readable, writable, and owned, by the user.
> That sounds like a good proposal...
>> Unless there be objections (or Glib be quickly patched), I'd be
>> filing a bug report against libglib2.0-0.
> ... but I don't think this is the right way to make it happen.
> Please research previous discussion to check that you're not missing
> arguments that have happened in the past,
Any particular pointers?
A scan over the past 2.5 years of gtk-devel-list@ archives
revealed nothing, and a brief Web search has only brought more
users disappointed by this behavior (e. g., [3]) and more
explicit work-arounds (e. g., [4].)
[3] http://bugs.irssi.org/index.php?do=details&task_id=532
[4] http://zathura.pwmt.org/projects/girara/doxygen/utils_8c_source.html
> then if you still think your proposal is the best option, take it
> upstream.
> I can see the value in having everything follow the same precedence,
> $HOME > getpwent - predictability is good. However, having Debian's
> GLib contradict behaviour that is specifically documented upstream
> doesn't sound as though it promotes predictability. If your proposal
> is good for Debian - which I think it is - then it's equally good for
> upstream.
Agreed.
I guess I should raise this issue on gtk-devel-list@.
--
FSF associate member #7257
Reply to: