>>>>> Simon McVittie <s...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/86r4povh7e....@gray.siamics.net