bug#12130: "sudo make install" applies umask to new directories

[Jason Eisner]

Dear Stefano - Thanks very much for your sympathetic reply on the directory permissions issue. As we haven't heard back further after a few days, I'd suggest going forward with plan 2.

You found that plan 2 was formerly proposed at <http://lists.gnu.org/archive/html/bug-automake/2003-05/msg00011.html>.  You suspected that it wasn't applied.  I believe that actually, it was applied, but then reverted because it broke someone's build.  As I wrote in a followup to my original post:

> Followup -- see this thread from 2004:
>     http://www.digipedia.pl/usenet/thread/16496/9413/
>
> Looks
>  like at one point, someone fixed this problem in the way I suggested.  
> But then a user on that thread found directory permissions of 755 too 
> restrictive, which may have gotten the fix removed.  
>
> One way to make everyone happy might be to ensure that a newly 
> created directory has permissions of *at least* 755.  (Although it's a 
> bit peculiar to handle directories this way when files are standardly 
> 644 ...)

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.  

By erring on the side of permissiveness, this hack allows "make install" to succeed from any user account (as I hoped), while still preserving backward compatibility (for the guy who complained above in 2004 that he wanted it to work differently from HIS user account). 

This is one of those backward compatibility hacks that results in inelegant behavior.  I wish the 2004 guy had not relied on getting umask permissions for directories (he couldn't have relied on umask permissions for files, since those are standardly 644).  But it might be worth it if anyone is still relying on this behavior.  If so, maybe the generated makefile should have a comment explaining that the "OR" with umask is only for backward compatibility with previous versions of automake.

cheers, jason