Hello,
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 ...
Thoughts?
Thanks,
R.
