On Fri, Aug 10, 2012 at 5:47 AM, Stefano Lattarini
<address@hidden> wrote:
This is something to consider carefully though, and only to be changed (if we decide to change it) in the next major automake version. For now, we
should content ourselves with the documentation fix you proposed.
When is the next major version? I'm guessing that a mere docfix won't help existing packages because they are unlikely to replace their documentation when they rerun automake (?).
> In other words, perhaps the mode of the newly created directory (the XXX in
> mkdir -p -m XXX) needs to be be the bitwise "OR" of 755 and the current
> umask.
>
I disagree. If we want to honour the user umask, we should do so fully;
half-hearted solutions (in one direction or another) will end up creating
confusion, and more problems than they solve.
Perhaps. But if you wish to preserve backward compatibility, that appears to require some degree of inconsistency (as is typical). In particular, it will require treating umask differently on files and directories, because that is what has been done in the past. Making the behavior consistent seems likely to break backward compatibility. If we start honoring umask on everything, that will break a large number of existing installation habits or scripts that relied on install to use 644 on files. If we start ignoring umask on everything, that will break a smaller number of existing installation habits or scripts that relied on a more permissive umask on directories (i.e., the guy who complained in 2004).
The only ways I can see to make it consistent between files and directories are to use the "OR" solution for both, or to ignore umask by default but have a command-line flag on "sudo make install" that says "please respect my umask" (for the few users who want to rely on it to get nonstandard installation permissions at their site).