Comment résoudre les erreurs d'autorisations sur OS X Lion après l'installation de Homebrew

Je viens de passer de Snow Leopard à Lion et j'essaie d'installer Homebrew. Cependant, après l'installation, je lance brew doctorselon les instructions d' installation et je vois une série d'erreurs indiquant que les répertoires / usr / local ne sont pas accessibles en écriture. Par exemple:

Error: /usr/local/share isn't writable.
This can happen if you "sudo make install" software that isn't managed
by Homebrew.

If a brew tries to write a file to this directory, the install will
fail during the link step.

You should probably `chown` /usr/local/share

Je les reçois pour un tas de répertoires:

You should probably `chown` /usr/local/include

You should probably `chown` /usr/local/share

You should probably `chown` /usr/local/share/man

Je ne peux pas comprendre pourquoi cette erreur se produit, car il semble que je fais partie du groupe Unix qui a des autorisations d'écriture sur ces répertoires:

Mini:~ felciano$ ls -ld /usr/local/share
drwxrwxr-x  4 root  admin  136 May 13 15:53 /usr/local/share
Mini:~ felciano$ whoami
felciano
Mini:~ felciano$ dscl . -read /Groups/admin GroupMembership
GroupMembership: root felciano
Mini:~ felciano$

Qu'est-ce que je rate?

EDIT: Le problème est maintenant résolu dans Homebrew:

• https://github.com/mxcl/homebrew/commit/8aa4f9dd3bbd885350776171d3d9403d381e1a59

Si vous rencontrez toujours le problème, mettez à jour Homebrew comme ceci:

brew update

Si vous voulez savoir quel était le problème, j'ai gardé ma réponse originale ci-dessous.

Ignorez le problème du permisson pour l'instant

Je rencontre exactement le même problème et, à mon avis, le problème se situe brew doctorplutôt que dans votre et mon installation.

Je pense que vous devriez ignorer le problème plutôt que de changer la propriété de /usr/local. Alternativement, vous pouvez corriger votre brew doctorscript local jusqu'à ce qu'un correctif soit publié. Voir ci-dessous.

Je ne considère pas correct de faire /usr/localappartenir à un utilisateur spécifique. J'ai plus d'un utilisateur administrateur sur cette machine. Vous devez laisser la /usr/localpropriété de en root:admintant que propriétaire et groupe.

Mon enquête

Comme pour vous, j'en ai un /usr/localqui est parfaitement accessible en écriture par mon utilisateur qui est également membre du admingroupe:

$ ls -ld /usr/local/
drwxrwxr-x  14 root  admin  476 22 Jun 23:33 /usr/local/
$ whoami
mgd
$ dscl . -read /Groups/admin GroupMembership
GroupMembership: root mgd rgd

Testons que le dir est vraiment accessible en écriture:

$ ls -l /usr/local/newfile
ls: /usr/local/newfile: No such file or directory
$ touch /usr/local/newfile
$ ls -l /usr/local/newfile
-rw-r--r--  1 mgd  admin  0 23 Jun 14:52 /usr/local/newfile

Une enquête plus approfondie sur le brew doctorcode m'a conduit à conclure que l'utilisation de la fonction rubis Pathname.writable?est à l'origine du problème. Considérez cette session Ruby interactive:

$ irb
>> require 'pathname'
=> true
>> Pathname('/usr/local').writable?
=> false

La fonction Pathname.writable?dit qu'elle /usr/localn'est pas accessible en écriture même si nous savons qu'elle l'est.

Utiliser à la Pathname.writable_real?place donne le résultat correct - il dit que le répertoire est accessible en écriture:

>> Pathname('/usr/local').writable_real?
=> true

Cela devrait être corrigé /usr/local/Library/Homebrew/cmd/doctor.rb. Vous pouvez le corriger dans votre propre installation en attendant un correctif.

La différence entre les deux fonctions est (selon les documents Ruby ici et ici ):

(nom_fichier) → vrai ou faux: renvoie vrai si le fichier nommé est accessible en écriture par l'ID utilisateur effectif de ce processus.

writable_real? (nom_fichier) → true ou false: renvoie vrai si le fichier nommé est accessible en écriture par l'ID utilisateur réel de ce processus.

Je crois que vous en avez juste besoin:

brew update

Réessayez brew doctorensuite.

Vous pouvez toujours obtenir des erreurs sur les dépendances que vous n'utilisez pas (Java dans mon cas), ce qui est correct. Si vous avez installé les outils de ligne de commande pour Xcode au lieu de l'installation complète de Xcode, vous obtiendrez également un message d'erreur indiquant que vous avez un chemin non valide, mais dans le message, vous lirez également qu'il n'y a pas de chemin valide si vous êtes en utilisant simplement les outils de ligne de commande pour Xcode, donc ça va aussi.

Pour le bénéfice des autres: Gardez à l'esprit que vous devez être connecté en tant qu'administrateur pour que cela fonctionne.

J'ai suivi une combinaison des suggestions d'iolsmit et de Phil M: j'ai chowné ces répertoires à mon nom d'utilisateur, puis j'ai couru à brew updatenouveau suivi de brew doctor. Cela s'est débarrassé de tous les messages d'erreur et les installations de brassage semblent maintenant fonctionner correctement. Merci à vous deux!

Bravo pour l'enquête et la clarification de @ mgd ... c'est parfait!

Il semble qu'un problème similaire ait été soulevé sur github.com il y a environ un an, mais n'a jamais été (correctement?) Résolu, du moins pas en utilisant writable_real?... peut-être qu'il est temps de faire une demande de tirage?!? :-)