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.
For instance, telepathy-glib uses this to make its regression tests work
on kFreeBSD (GDBus writes to g_get_home_dir() to implement D-Bus
authentication, on non-Linux platforms where it doesn't support
credentials-passing).
> Note that in contrast to traditional UNIX tools, this function
> prefers passwd entries over the HOME environment variable.
...
> 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.
> 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, 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.
S
--
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/5063322b.7040...@debian.org
