question for the "base gurus"

René J.V. Bertin rjvbertin at
Tue Jan 24 15:22:39 UTC 2017


You know I use a very slightly adapted version of "base" to use MacPorts on Linux. This is about an intermittent issue I see there that happens in code which I think should be host/OS *independent*.

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

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

I have been assuming that the issue might be a side-effect of running on ZFS, but that doesn't fit in with strace showing me a call to chmod(".../pkgconfig", 0255).

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



More information about the macports-dev mailing list