question for the "base gurus"

[Clemens Lang]

On Tue, Jan 24, 2017 at 04:22:39PM +0100, René J.V. Bertin wrote:
> I have mentioned before that I sometimes get permissions errors during
> the destroot phase because directories created with xinstall don't
> have the intended umask. This happens episodically, and this morning I
> had one of those episodes, plus some time to look into it.
> 
> In the end, I had 2 commands that should give the same result:
> 
> %> strace -o strace.log port -nok destroot foo
> %> strace port -nok destroot foo >& strace.log

Remember that files that have been present in destroot before might
affect the result, too. Some ports' destroot phases are written in ways
that they cannot be repeated (that doesn't seem to be the case here, but
it's worth keeping it in mind).

> The latter form succeeded, while the former failed because at loosely
> predictable some point a ${destroot}${prefix}/lib/pkgconfig received
> the umask 0255 instead of 0755 or 0775. Loosely predictable here means
> that it occurred during a reinplace loop over the .pc files in the
> pkgconfig directory.

The only difference in MacPorts behavior I would expect here is the
check whether output is to a terminal.

> The episode stopped before I could run the destroot command through
> valgrind.
> 
> I've been looking at pextlib's install.c hoping to find a possibility
> that the mode (umask) variable could be used without proper
> initialisation, but that shouldn't be possible. Not in install.c in
> any case, but could there be a reason to assume that the argument
> parsing goes wrong somewhere?

If that's something you suspect, I recommend you compile a copy of
Pextlib with address sanitizer. Since Pextlib is probably dlopen(3)'d by
Tcl at runtime, you may have to preload the address sanitizer libraries,
but (at least on OS X) the binary will tell you that.

> Either way, I think that install.c's install_dir() really shouldn't
> ignore chmod() errors silently ...

Patch to add error checking welcome.

-- 
Clemens