Est-il prudent d’installer Homebrew et Macports sur le même ordinateur?
MacPorts est installé sur mon iMac avec un assez grand nombre de ports installés.
Je voudrais cependant essayer Homebrew, car j’ai entendu beaucoup de bonnes choses à ce sujet et parce que j’ai remarqué qu’il contenait des versions plus récentes de plusieurs des outils que j’utilisais.
Mais les deux peuvent-ils coexister sur le même ordinateur ou dois-je désinstaller entièrement MacPorts en premier?
De plus, si les deux peuvent être installés en même temps, seront-ils complètement indépendants l'un de l'autre? L’une des fonctionnalités de Homebrew est qu’il ne réinstalle pas les nouvelles versions des éléments déjà inclus dans le système (par exemple, python). Est-ce que cela s’étend aussi à ce qu’il n’installe pas de version de choses déjà gérées par MacPorts?
Que se passe-t-il si, par la suite, je désinstalle MacPorts?
Ils ne vont pas bien coexister. Le gcc Apple cherche dans/usr/local certaines choses. Cela signifie qu'une compilation macports pourrait trouver quelque chose que le porteur ne s'attendait pas. Voir les listes de diffusion et les bogues de macports pour des exemples d'éléments trouvés dans/usr/local.
J'ai donné une autre réponse à une question similaire:
Homebrew posera des problèmes lors de la construction du logiciel à partir de la source s'il est installé dans/usr/local. C'est le choix par défaut, ce qui est un mauvais choix car ce chemin est dans le chemin de recherche par défaut des compilateurs et autres outils. Par conséquent, les compilations à partir d'autres logiciels de packaging risquent de générer la mauvaise dépendance, en utilisant la version de Homebrew au lieu de la leur.
Il y a des années, au tout début du projet, même MacPorts utilisait/usr/local. Mais il s'est avéré qu'il ne fallait pas coopérer avec d'autres outils, comme le décrit leur FAQ. Malheureusement, les développeurs Homebrew n'ont pas voulu entendre parler d'expériences antérieures et ont ignoré de tels faits ...
En général, il est généralement préférable de s’en tenir à un seul outil pour éviter tous les problèmes. MacPorts fait de son mieux pour corriger les chemins codés, par exemple. to/sw qui est utilisé par Fink. Généralement, cela fonctionnera, mais tout ce qui est installé dans/usr/local posera certainement des problèmes.
[…]
J'avais l'habitude de penser que les inquiétudes sur ce que les outils de construction Gnu vont faire de /usr/local étaient à la limite de la paranoïa. Les outils de construction prévoient qu'il y ait beaucoup de choses là-bas: au bon vieux temps avant les gestionnaires de paquets (je plaisante), nous avons compilé n'importe quoi pour /usr/local. Cependant, alors qu'Autoconf résout généralement les problèmes, la complexité de la construction de nombreux projets open source pose problème et il peut être difficile de résoudre ces problèmes lorsque vous rencontrez des difficultés.
Mais le risque de problèmes avec Autoconf à trouver quelque chose qui ne devrait pas être sous /usr/local doit être pris en compte par la nuisance liée à la maintenance avec deux, trois ou quatre copies différentes de Perl, Tcl et Ruby, chacune avec une couverture différente de leurs différentes bibliothèques de paquets. . Désagréable.
Étant donné que mon expérience avec MacPorts et Fink est généralement due à l'exaspération, et qu'à un moment donné, je suis passée à la compilation de l'ancienne méthode en /usr/local, j'ai été ravie de constater que Homebrew ne plaisait pas avec cela. J'ai essayé de configurer MacPorts pour qu'il installe /usr/local, mais MacPorts fait tout son possible pour rendre cela difficile. Je comprends que la motivation est de se rendre la vie plus facile quand il s’agit de demander de l’aide sur leur liste de diffusion et leur traqueur de bogues; sachez cependant que, même si nous devons respecter les efforts des emballeurs volontaires et traiter leur temps comme étant précieux, Le confort du débogage n’est pas la seule sorte de simplicité qui vous concerne, en tant qu’utilisateur.
Homebrew, du moins à cet égard, procède comme avant, et MacPorts tente de ne pas interférer. Si vous êtes disposé à documenter les paquets dont vous avez besoin avec Homebrew, et effacer/usr/local à nettoyer et à réinstaller en cas de difficulté, vous pouvez toujours faire marche arrière si les choses tournent mal. Et une fois que vous réaliserez que les problèmes rencontrés dans/usr/local n'entraînent généralement pas de risque d'endommagement permanent de vos machines, vous pouvez vous sentir plus libre de prendre des risques.
Je vais simplement souligner combien le conditionnement sur OSX est pire que sur FreeBSD: Apple ne semble pas vraiment se soucier de la convivialité de son sous-système BSD, car c’est un problème qu’ils pourraient résoudre.
Selon la MacPorts FAQ :
Notez qu'à partir de la version 2.3.0, MacPorts peut automatiquement masquer/usr/local (et tous les autres fichiers dont le port ne dépend pas) des systèmes de construction de ces ports. Cette fonctionnalité s'appelle le mode trace et est activée en fournissant l'indicateur -t au port, par exemple.
Sudo port -t install <portname>
Ceci est pertinent car, selon la page d'installation Homebrew:
Une des raisons pour lesquelles Homebrew ne fonctionne que par rapport à la concurrence est que nous recommandons d’installer à/usr/local. Choisissez un autre préfixe à vos risques et périls!
Par conséquent, et avec peu d’expérience personnelle, je pense que le fait de toujours utiliser l’option -t pour les installations MacPort devrait éviter la plupart des problèmes de coexistence de MacPorts et de Homebrew sur le même système. Pour répondre à votre dernière question: je ne vois aucune raison pour laquelle la désinstallation de MacPorts causerait des problèmes.
Lors de l'installation de l'homebrew sur un ordinateur sur lequel je travaille depuis des années, voici ce que je peux lire:
Warning: You have MacPorts or Fink installed:
/opt/local/bin/port
This can cause trouble. You don't have to uninstall them, but you may want to
temporarily move them out of the way, e.g.
Sudo mv /opt/local ~/macports
Faites attention!
la solution Sudo port -t ... de webappzero devrait vous aider. Pour être honnête, je cours avec Fink, MacPorts et Homebrew en même temps, avec déférence pour MacPorts (pour l’instant de toute façon), et en utilisant l’un des deux autres uniquement pour installer des éléments que je ne peux pas obtenir de MacPorts. J'ai rencontré très peu de difficultés de cette façon, avant même d'apprendre l'astuce port -t. Si vous essayez d'utiliser plusieurs gestionnaires de packages pour maintenir des environnements de développement et de serveur complexes, vous êtes probablement dans un monde au moins inconfortable. Choisissez-en un et évitez les autres, mais pour quelque chose dont vous avez désespérément besoin, et mettez le principal plus tôt dans le chemin.
Si ce que j'entends dire est vrai, Apple interdira l'installation d'éléments dans/usr/autres que ceux d'Apple (ou peut-être le font-ils déjà dans El Crapitan, pour lequel j'évite de "mettre à niveau" les problèmes avec ce problème sont résolus), je suppose que cela atténuera le problème après que Homebrew aura par défaut utilisé autre chose - que nous soyons d’accord ou non avec l’approche brutale d’Apple.
En fin de compte, j'aime bien l'idée de confiner les propres ports d'Apple à son propre arbre. J'aimerais seulement que ce ne soit pas/usr /. Je préférerais qu'ils utilisent/System/bin /, etc., etc., pour isoler leurs propres fichiers, afin de pouvoir les contourner plus facilement avec des logiciels mis à jour et maintenus par la communauté.