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'en ai entendu beaucoup de bonnes choses et parce que j'ai remarqué qu'il contenait des versions plus récentes de plusieurs des outils que j'utilise.

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 une 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 tous les chemins codés, par exemple vers / sw 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 l'inquiétude que suscitaient les outils de construction Gnu /usr/localétait presque paranoïaque. Les outils de construction s’attendent à beaucoup de choses: dans le bon vieux temps avant que les gestionnaires de paquets (je plaisante), nous compilions tout ce que nous voulions /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 en trouvant quelque chose qui ne devrait pas être sous- /usr/localestimé doit être pris en compte par le problème de 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 a généralement été exaspérée par ce phénomène, et qu’à un moment donné /usr/local, je suis heureuse de voir qu’Homebrew ne plaisante pas avec cela. J'ai essayé de configurer MacPorts pour l'installer /usr/local, mais MacPorts fait tout son possible pour rendre cela difficile. Je comprends que la motivation est de se simplifier la vie lorsque des demandes d’aide sont formulées 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 précieux, leur 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, fait les choses 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 revenir en cas de problème. Et une fois que vous réaliserez que les problèmes rencontrés dans / usr / local ne comportent 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 FAQ MacPorts :

Notez qu'à partir de la version 2.3.0, MacPorts peut automatiquement masquer / usr / local (et tous les autres fichiers dont un 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 une expérience personnelle limitée, je pense que le fait de toujours utiliser l'indicateur -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 que la désinstallation de MacPorts pose problème.

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 sudo port -t ...solution de webappzero devrait 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 n’utilisant que l’un des deux autres 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 le port -ttruc. 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 la trajectoire.

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 elle 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 avec l’approche lourde d’Apple ou non.

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 aient utilisé / 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é.