[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ${HOME} vs. g_get_home_dir () [and 1 more messages]

Ivan Shmakov writes ("${HOME} vs. g_get_home_dir ()"):
> 	I do remember filing a bug or two against packages that refer to
> 	the getent () data to find the user's “home” directory instead
> 	of using the HOME environment variable.

I agree with your complaint.  Programs should honour $HOME for the
current user, and not use getpwuid(getuid())->pw_dir.

Using pw_dir is an acceptable workaround, I guess, if the directory is
unsuitable by reason of its permissions.

> 	Unless there be objections (or Glib be quickly patched), I'd be
> 	filing a bug report against libglib2.0-0.

Please do.

Simon McVittie writes ("Re: ${HOME} vs. g_get_home_dir ()"):
> 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.

I think this is plainly a workaround for the buggy failure to honour

> 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.

Clearly if the manpage and the code disagree there is a bug.  But it
seems that there is some doubt about in which direction the fix should
be made.

> 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.

It is certainly a good idea to research previous discussion, and give
upstream the opportunity to comment.  And we should listen
respectfully to what upstream have to say.  I'm a great fan of the
concept of Chesterton's Fence, especially in programming.

But I think the right way to organise and track the issue here in
Debian is a bug in our BTS.

And if upstream don't think the behaviour is wrong but we don't find
their explanation convincing, their opposition should not block the
fix in Debian.  One of the useful things Debian can do for our users
is to fix mistakes made by upstreams - our wider experience, mature
governance processes and closer relationship with the users gives us
that opportunity and responsibility.

> 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.

Well, that's true, but of course we are entiotled to disagree with and
diverge from upstream.  But first we should understand why the
decision was made.

Looking at the bug logs found so far it seems to be due to users
having difficulty with sudo etc.  Ivan's proposal would address that.


Reply to: