On 08/03/2012 06:06 AM, Jason Eisner wrote: > Hi automake folks, > Hi Jason, thanks for the report.
> There are many, many generic and specific installation guides that tell you > to type something like > ./configure && make && sudo make install > and I've been typing that for years. > > Unfortunately, when installing OpenFST, I just discovered that the "sudo > make install" part doesn't always work. My umask is 0077, so any > directories created with sudo (hence owned by root) are unreadable to > ordinary users, including myself. > This is indeed annoying. > Since following the documentation yields mysterious error messages and > hard-to-fix errors[*] rather than the intended behavior, I believe that you > should make ONE of the following changes: > > 1. Fix the documentation: Correct the instructions to users to warn them > that they should reset their umask before typing sudo make install. > This sounds like a good idea. Care to attempt a patch? Otherwise, I'll get to write it myself eventually (not right now). But then, reading further ... > 2. Fix the behavior: Have "make install" set the permissions on > directories, just as it already does on files. For example, by using -m > 755 as an option to mkdir, or otherwise overriding the umask. > ... I see that a patch in this direction had already been proposed: <http://lists.gnu.org/archive/html/bug-automake/2003-05/msg00011.html> but apparently never applied (the discussion died out). Maybe we could just resurrect it ... Any opinion from the other autotoolers? > 3. Don't fix the behavior outright, if you think for some reason that the > user's umask should sometimes be respected on new directories. But then at > least have "make install" issue a warning > That would likely be lost in the very verbose "make install" output, sadly. > or a y/n prompt when the current umask > Oh no, our rules are not going to get interactive by default; not even conditionally ("if input/output is attached to a terminal, then print a prompt and ..."). There lies madness. >(or for that matter, restrictive permissions on existing directories) > would result in installed resources that are not publicly readable. > > My own preference would be for 2. > I'm undecided among 1 and 2, but leaning toward 2 by now. I'll wait a few days for some feedback by the other autotoolers before proceeding. > I can't understand why make install > treats directory permissions inconsistently with file permissions. > I'd guess hysterical raisins -- as is the case with many other warts and rough edges in Automake. > And I can't see why a single-user preference like a umask should be > reflected in a global installation. > I agree it shouldn't. > However, if there is some reason not to do 2., then I think you should do > 1. or 3. to save at least some of the headaches.[*] > > This problem doesn't affect all packages -- only installations that create > new directories. But it has been raised repeatedly over the years. To > find numerous past reports, just do websearches such as > umask automake > Thanks for this suggestion. It pointed me to the older patch I referenced above. > umask directories "make install" > However, I think it has usually been raised with maintainers of downstream > packages, who are not equipped to fix it. Nothing comes up when I search > for umask on http://lists.gnu.org/archive/html/bug-automake/ . > > Thanks a lot for your attention! > > -jason > > [*] Following the standard installation instructions leads to a silent > failure of installation. The cockeyed installation can result in > mysterious error messages when you try to use it. E.g., I got messages > saying that the command-line utilities couldn't find their .so files. > Fixing the mistaken permissions is also tricky. Even if you figure out > that your umask was at fault, you can't just change your umask and run > "sudo make install" again. That's because the directories already exist > and rerunning "mkdir -p" on them is a no-op. So you have to figure out > which directories were created and chmod them manually. I hope this makes > clear why having some kind of fix is important ... > Thanks, Stefano