Comment savoir quel fichier appartient à quel package sous Mac OS X?

8

Existe-t-il un moyen de savoir quelle application / package possède ou crée un fichier spécifique? Par exemple, sous Linux, ces commandes afficheront le propriétaire du package

apt-file /bin/progname

rpm -qf /bin/progname

yum whatprovides /bin/progname

Sous OS X, un fichier peut faire partie d'une application OS X native ou être installé par Macports ou Homebrew. Ce sont des environnements complètement différents. Existe-t-il des commandes pour chaque environnement pour vérifier quelle application / package possède un fichier spécifique?

— hanxue
source

19

Il est un peu tard, mais ce sera peut-être utile aux autres.

Vous pouvez utiliser la pkgutilcommande.

Par exemple, si vous voulez savoir quel package la commande "less" appartient à exécuter:

pkgutil --file-info /usr/bin/less

Qui produira quelque chose comme:

volume: /
path: /usr/bin/less

pkgid: com.apple.pkg.BaseSystemBinaries
pkg-version: 10.7.0.1.1.1309742044
install-time: 1310407891
uid: 0
gid: 0
mode: 755

Pour répertorier tous les fichiers contenus dans un package, com.apple.pkg.BaseSystemBinariesdans notre exemple, exécutez:

pkgutil --files com.apple.pkg.BaseSystemBinaries

Je sais que cet outil est présent depuis OS X 10.6.

— bhavin
source

Cela devrait être marqué comme la bonne réponse. Vous pouvez même l'utiliser avec des applications GUI. Essayez pkgutil --file-info /Applications/TextEdit.app, et vous obtiendrez qu'il appartient à com.apple.pkg.Essentials, mais vous indiquera également les mises à jour qui lui ont été appliquées (dans mon cas, com.apple.pkg.update.os.10.10.2.14C109 .patch, com.apple.pkg.update.os.10.10.3.14D131.delta, com.apple.pkg.update.os.10.9.2.13C64.combo).

— juandesant

5

Ce n'est pas vraiment possible car il n'y a pas de gestion standardisée des packages.

Sauf si vous avez configuré MacPorts ou Homebrew différemment, vous trouverez toujours leurs exécutables dans un emplacement que personne d'autre n'utilise. Étant donné que MacPorts et Homebrew ne s'exécutent pas sous un compte d'utilisateur distinct, les fichiers qu'ils créent seront toujours la propriété de votre utilisateur ou root.

Ce qui reste, c'est que vous ne pouvez essayer de deviner que sur la base de l'emplacement exécutable. Voici quelques règles:

MacPorts utilise /opt/local/binet /opt/local/sbinpour les exécutables, tout préfixé sous /opt/local.
Homebrew utilise /usr/local/binpour les exécutables, tout le reste sous /usr/local/.
D'autres applications devraient créer leurs propres répertoires quelque part sous /usr, par exemple /usr/local/git/binpour le programme d'installation de Git OS X ou /usr/X11/binpour X11.
Certains cadres du système lien symbolique /usr/bin, par exemple des rakepoints à/System/Library/Frameworks/Ruby.framework
Aucune application ne doit jamais utiliser /binou /sbin. Aucune application tierce (c'est-à-dire tout ce qui n'est pas un framework OS X) ne devrait utiliser /usr/binnon plus.

— slhck
source

Ce n'est pas vrai qu'il n'y a pas de gestion standardisée des packages. Mac OS X installe presque tous les logiciels à partir de packages (à l'aide du programme d'installation) et conserve un enregistrement. Voir la réponse de @bhavin.

— Neil Mayhew

1

Tu as raison. Je parlais plutôt des programmes qui n'utilisaient peut-être pas de packages standard. Je ne savais pas grand-chose sur pkgutil lorsque j'ai écrit cette réponse.

— slhck

Je ne savais pas non pkgutilplus, et cela semble assez pratique.

— Neil Mayhew

Avec MacPorts, vous pouvez savoir quel port possède un fichier particulier en utilisantport provides FILE

— Neil Mayhew

2

Pour les collecter en un seul endroit pour les deux autres gestionnaires de packages sur OSX:

Pour MacPorts (comme mentionné par Neil dans les commentaires ci-dessus):

port provides /opt/local/bin/progname

Pour Brew, ce n'est pas si simple, mais on peut généralement trouver le package en utilisant:

ls -la /usr/local/bin/progname

Qui devrait afficher un lien logiciel contenant le nom du package, ou bien on peut utiliser d'autres suggestions de l' une de ces questions .

— Pierz
source