Question Est-il sécuritaire d'installer Homebrew et Macports sur le même ordinateur?


J'ai MacPorts installé sur mon iMac avec un bon nombre de ports installés.

Je suis intéressé à essayer Homebrew, car j'ai entendu beaucoup de bonnes choses à ce sujet, et parce que j'ai remarqué qu'il contient plus de versions à jour de plusieurs des outils que j'utilise.

Mais les deux peuvent-ils coexister sur le même ordinateur ou dois-je désinstaller MacPorts en premier?

Aussi, si les deux pouvez être installé en même temps, seront-ils complètement indépendants les uns des autres? L'une des fonctionnalités de Homebrew est de ne pas réinstaller les nouvelles versions des éléments déjà inclus dans le système (par exemple, python). Est-ce que cela ne s'étend pas à l'installation de versions déjà gérées par MacPorts?

Que se passe-t-il si je désinstalle ensuite MacPorts?


68
2017-08-27 11:24


origine




Réponses:


Ils ne coexisteront pas bien ensemble. Le gcc d'Apple regarde dans / usr / local pour certaines choses. Cela signifie qu'une compilation de macports pourrait trouver quelque chose auquel le porteur ne s'attendait pas. Voir les listes de diffusion et les bogues des macports pour des exemples de choses trouvées dans / usr / local.


22
2017-08-27 11:45



Je n’ai eu qu’un aperçu superficiel de l’homebrew, mais si vous changiez l’emplacement d’installation par défaut de homebrew de / usr / local à / opt / homebrew / usr / local, ce problème serait-il évité? - Babu
@Babu - Selon brassage, vous devriez procéder avec prudence - Peter Ajtai
@babu - peut-être mais il y aura des problèmes avec lesquels des homebrews ou des macports seront pré-installés sur le chemin et l’autre qui récupérera ces exécutables aussi - Mark


j'ai donné une autre réponse sur une question similaire:

Homebrew causera des problèmes lors de la construction de logiciels à partir de la source si elle   est installé dans / usr / local. C'est le défaut, ce qui est un mauvais choix   comme ce chemin est dans le chemin de recherche par défaut des compilateurs et autres   outils. Par conséquent, les compilations d’autres logiciels d’emballage peuvent   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 était   en utilisant / usr / local. Mais il s'est avéré ne pas coopérer avec d'autres outils   comme cela est documenté dans leur FAQ. Malheureusement, les développeurs Homebrew   n'a pas voulu entendre parler d'expériences antérieures et a 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 réparer tout harcodé   chemins, par ex. to / sw qui est utilisé par Fink. Donc, en général, cela fonctionnera, mais   avoir quelque chose installé dans / usr / local posera certainement des problèmes   pour ça.

[...]


17
2017-09-12 19:04



On dirait qu'il est également possible d'installer un homebrew dans ~/.homebrew. Serait-il toujours interférer avec MacPorts s'il est installé à la place? - Behrang
Tout autre emplacement que / usr / local devrait être correct. - raimue
MacPort et Homebrew coexisteront-ils bien si on installait Homebrew sur / opt / local, où MacPort est installé? - Adam L. S.
Vous ne devez pas installer d'autres logiciels manuellement dans / opt / local lorsque MacPorts y est déjà installé. Il va certainement interférer lorsque vous placez des fichiers inconnus de MacPorts, ce qui entraîne des conflits lors de l'installation des ports. - raimue


J'avais l'habitude de penser que ce qui préoccupe les outils de construction de Gnu /usr/local étaient à la limite de la paranoïa. Les outils de construction attendre il y avait beaucoup de choses là-bas: dans le bon vieux temps avant que les gestionnaires de paquets (je blague), nous avons compilé tout pour /usr/local. Bien qu'Autoconf détecte généralement les problèmes, la complexité même de nombreux projets open-source pose des problèmes et il est parfois difficile de résoudre ces problèmes lorsque vous rencontrez des difficultés.

Mais le risque de problèmes avec Autoconf trouver quelque chose qu'il ne devrait pas sous /usr/local doit être équilibré en ce qui concerne 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é une source d’exaspération due à cela, et à un moment donné, nous avons commencé à compiler la /usr/local, J'ai été ravi de voir que Homebrew n'a pas joué avec ça. J'ai essayé de configurer MacPorts pour installer /usr/local, mais MacPorts fait tout son possible pour rendre cela difficile. Je comprends que la motivation est de se simplifier la vie en traitant les appels à l’aide sur leur liste de diffusion et leur outil de suivi des bogues: sachez que nous devons respecter l’effort des emballeurs volontaires et traiter leur temps comme précieux. la facilité de débogage n'est pas le seul type de simplicité qui vous affecte, en tant qu'utilisateur.

Homebrew, à cet égard au moins, fait les choses comme avant, et MacPorts essaie de ne pas intervenir. Si vous êtes disposé à documenter les paquets dont vous avez besoin avec Homebrew, et à effacer / usr / local clean et à réinstaller en cas de difficultés, vous pouvez toujours revenir en arrière si les choses tournent mal. Et une fois que vous réalisez que les problèmes de / usr / local ne comportent généralement pas de risque de dommages permanents à vos machines, vous pouvez vous sentir plus libre de prendre des risques.

Je me contenterai de noter à quel point l’emballage est pire sur OSX que sur FreeBSD: Apple ne semble pas vraiment s’inquiéter de la facilité d’utilisation de son sous-système BSD, car c’est un problème qu’ils pourraient résoudre.


8
2017-11-26 12:43



Eh bien, ma question est posée du point de vue d'un utilisateur bête qui utilise le gestionnaire de paquets pour "obtenir des choses". Ce n'est pas du tout certain que je serais capable "comprendre les choses un peu [mon] moi si les choses tournent mal." Encore, soulève quand même pour la clarification supplémentaire. Merci! - Rich
MacPorts comme bonnes raisons de ne pas utiliser / usr / local, voir trac.macports.org/wiki/FAQ#defaultprefix - raimue
@Raim: Bonnes raisons pour cela - il s'agit plutôt d'un compromis entre la facilité de suivi des bogues et la simplicité de l'installation sur la machine de l'utilisateur. Je me soucie de ce dernier. - Charles Stewart
Le nombre de choses qui peuvent mal tourner parce que quelqu'un (ou quelque chose) a installé une copie de $ lib dans /usr/local est sans fin. Des architectures, des versions, des fonctionnalités et des indicateurs configurés, des installations partielles, des installations obsolètes présentant des problèmes de sécurité et qui causeront des problèmes. Bien sûr, allez-y si vous savez ce que vous faites, mais ne déposez pas de bugs à ce sujet. L’expérience montre que les gens déposent des bogues de toute façon, et c’est exactement la raison pour laquelle le mode trace (-t, voir ci-dessous) existe et pourquoi éviter /usr/local est la recommandation par défaut. - neverpanic
@neverpanic - Mon opinion sur les risques de tout compiler sur / usr / local a changé depuis que j'ai écrit cette réponse, principalement parce que la complexité des projets open-source augmente et que les problèmes d'Autoconf ne sont pas plus faciles à résoudre. trier: au moins, "à la limite paranoïaque" est injuste. Cependant, je n'aime toujours pas l'approche "propre univers de compilation privée" de Macports, et cela mérite de souligner que la simplicité des interactions avec les listes de diffusion n'est pas le seul type de simplicité dont l'utilisateur doit se soucier. Je vais ajouter des réserves à ma réponse. - Charles Stewart


Selon le FAQ MacPorts:

Notez qu'à partir de 2.3.0, MacPorts peut automatiquement masquer   / usr / local (et tous les autres fichiers dont un port ne dépend pas) des ports '   construire des systèmes. Cette fonctionnalité est appelée mode trace et est activée par   fournir le drapeau -t au port, par ex.

sudo port -t install <portname>

Ceci est pertinent car selon la page d'installation de Homebrew:

L’une des raisons pour lesquelles Homebrew ne travaille que par rapport à la concurrence est   car nous recommandons d’installer sur / usr / local. Choisissez un autre préfixe à   votre péril!

Par conséquent, et avec peu d'expérience personnelle, je pense qu'en utilisant toujours l'option -t pour les installations MacPort, la plupart des problèmes liés à la coexistence de MacPorts et de Homebrew sur le même système devraient être évités. Pour répondre à votre dernière question: je ne vois aucune raison pour laquelle la désinstallation de MacPorts poserait des problèmes.


5
2017-10-23 20:00



Sachez que vous subirez une pénalité de performance importante. Mais en général, cela devrait fonctionner dans presque tous les cas. - neverpanic
Merci de souligner cette mise en garde @neverpanic. Je suppose que cette pénalité de performance affecte uniquement le temps d’installation du port et n’a aucun effet sur les caractéristiques d’exécution du port installé. Vrai? - webappzero
Correct. Cela empêche uniquement les problèmes de construction, pas les problèmes d'exécution (mais ils sont très rares). - neverpanic
En pratique, je ne me suis pas souvenu de cette exigence de toujours utiliser l'indicateur de trace. Par conséquent, je ne recommande pas cette pratique à d'autres, à moins que vous ne soyez certain que vous utiliserez -t systématiquement. - webappzero
Si vous ne voulez pas vous en souvenir, vous pouvez écrire un script de wrapper ou un alias de shell (mais soyez conscient de l'interaction entre les alias de sudo et de shell) pour toujours le transmettre pour vous. Notez que El Capitan interrompt actuellement le mode trace. Je travaille sur une solution de contournement. - neverpanic


En installant homebrew sur un ordinateur sur lequel j'utilise les ports 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!


4
2018-03-18 15:07





webappzero's sudo port -t ... solution 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 utilisant l’un des deux autres pour installer des choses que je ne peux pas obtenir de MacPorts. J'ai rencontré très peu de difficultés de cette façon, même avant port -t tour. Si vous essayez d'utiliser plusieurs gestionnaires de paquets pour maintenir des environnements de développement et de serveur complexes, vous êtes probablement confronté à un monde d'inconfort. Choisissez-en un et évitez les autres mais pour quelque chose dont vous avez désespérément besoin, et placez le plus tôt dans le chemin.

Si ce que j'entends est vrai à propos d’Apple qui va interdire l’installation de fichiers dans / usr / autres que ceux d’Apple (ou peut-être qu’ils le font déjà dans El Crapitan, que j’évite de classer jusqu’à plus les problèmes avec elle sont résolus), je suppose que cela atténuera le problème après que Homebrew utilise par défaut autre chose - si nous sommes d'accord avec l'approche lourde d'Apple ou non.

En fin de compte, j'aime l'idée de confiner les propres ports d'Apple à son propre arbre, je souhaite juste que ce ne soit pas / usr /. Je préférerais qu'ils aient utilisé / System / bin /, etc., etc. pour isoler leurs propres éléments, afin de pouvoir les contourner plus facilement avec des logiciels mis à jour et gérés par la communauté.


1
2017-12-06 06:41