Ist es sicher, Homebrew und Macports auf demselben Computer zu installieren?

35348
Rich

Ich habe MacPorts auf meinem iMac installiert, auf denen ziemlich viele Ports installiert sind.

Ich bin jedoch daran interessiert, Homebrew auszuprobieren, da ich viele gute Dinge darüber gehört habe und weil mir aufgefallen ist, dass es aktuellere Versionen einiger der von mir verwendeten Tools enthält.

Können die beiden auf dem gleichen Computer vorhanden sein oder muss ich MacPorts zuerst vollständig deinstallieren?

Auch wenn die beiden können gleichzeitig installiert werden, werden sie völlig unabhängig voneinander? Eine der Funktionen von Homebrew ist, dass keine neuen Versionen von Dingen, die bereits im System enthalten sind (z. B. Python), nicht neu installiert werden. Gilt dies auch für die Installation von Versionen von Dingen, die bereits von MacPorts verwaltet werden?

Was passiert, wenn ich anschließend MacPorts deinstalliere?

68

6 Antworten auf die Frage

22
Mark

Sie werden nicht gut miteinander koexistieren. Das Apple gcc sucht in / usr / local nach einigen Dingen. Dies bedeutet, dass ein Macports-Compile etwas finden konnte, das der Portier nicht erwartet hatte. In macports-Mail-Listen und -Bugs finden Sie Beispiele für Dinge, die in / usr / local zu finden sind.

Ich habe nur einen sehr flüchtigen Blick auf Homebrew gehabt, aber wenn Sie den Standardinstallationspfad für Homebrew von / usr / local in etwas wie / opt / homebrew / usr / local geändert haben, würde dieses Problem vermieden werden? Babu vor 14 Jahren 4
@Babu - Laut Brew sollten Sie [mit Vorsicht vorgehen] (https://github.com/mxcl/homebrew/wiki/Installation#wiki-fn4) Peter Ajtai vor 12 Jahren 0
@babu - möglicherweise wird es aber Probleme geben, mit welchen von Homebrew oder Macports der Pfad und der andere die ausführbaren Dateien abholen. Ich vermute auch, dass die Ports beider Systeme nicht vollständig mit einem anderen Pfad getestet wurden Mark vor 12 Jahren 0
17
raimue

Ich habe eine andere Antwort auf eine ähnliche Frage gegeben:

Homebrew verursacht Probleme beim Erstellen von Software aus der Quelle, wenn diese in / usr / local installiert wird. Dies ist die Standardeinstellung, eine schlechte Wahl, da sich dieser Pfad im Standardsuchpfad von Compilern und anderen Tools befindet. Daher können Builds anderer Verpackungssoftware die falsche Abhängigkeit aufgreifen, indem sie die Version von Homebrew anstelle ihrer eigenen verwenden.

Vor Jahren, zu Beginn des Projekts, verwendete sogar MacPorts / usr / local. Es stellte sich jedoch heraus, nicht mit anderen Tools zusammenzuarbeiten, wie dies in den häufig gestellten Fragen beschrieben ist. Homebrew-Entwickler wollten leider nicht von früheren Erfahrungen erfahren und ignorierten solche Fakten ...

Im Allgemeinen ist es in der Regel besser, nur ein Werkzeug zu verwenden, um alle Probleme zu vermeiden. MacPorts bemüht sich, harcodierte Pfade zu patchen, z. B. nach / sw, das von Fink verwendet wird. Normalerweise wird es funktionieren, aber alles, was in / usr / local installiert ist, wird definitiv Probleme verursachen.

[…]

Anscheinend ist es auch möglich, Homebrew in `~ / .homebrew` zu installieren. Würde es immer noch MacPorts stören, wenn es stattdessen dort installiert wird? Behrang vor 12 Jahren 0
Jeder andere Ort als / usr / local sollte in Ordnung sein. raimue vor 12 Jahren 0
Werden MacPort und Homebrew gut koexistieren, wenn Homebrew unter / opt / local installiert wird, wo MacPort installiert ist? Adam L. S. vor 10 Jahren 0
Sie sollten keine andere Software manuell in / opt / local installieren, wenn MacPorts dort bereits installiert ist. Dies wird definitiv stören, wenn Sie Dateien ablegen, die MacPorts nicht kennen, was zu Konflikten bei der Installation von Ports führt. raimue vor 10 Jahren 1
8
Charles Stewart

Ich dachte immer, dass die Sorge darüber, was die Gnu-Build-Tools machen werden, /usr/localparanoid ist. Die Build-Tools erwarten dort viele Dinge: In den guten alten Tagen vor Paketmanagern (ich scherze) haben wir alles zusammengestellt /usr/local. Während Autoconf normalerweise Probleme aufdeckt, führt die schiere Komplexität vieler Open-Source-Projekte zu Problemen. Diese Probleme lassen sich nur schwer beheben, wenn Sie in Schwierigkeiten geraten.

Aber das Risiko, dass Autoconf etwas findet, das es nicht sein sollte, /usr/localmuss im Hinblick auf die Wartungsprobleme abgewogen werden, wenn zwei, drei oder vier verschiedene Kopien von Perl, Tcl und Ruby vorhanden sind, von denen jede unterschiedliche Paketbibliotheken umfasst. Unangenehm.

Da meine Erfahrung mit MacPorts und Fink in der Regel ärgerlich war und irgendwann auf die altmodische Art und Weise /usr/localumgestellt wurde, freute ich mich, dass Homebrew sich nicht damit beschäftigt hat. Ich habe versucht, MacPorts für die Installation zu konfigurieren /usr/local, aber MacPorts macht alles, um dies zu erschweren. Ich verstehe, dass die Motivation darin besteht, sich das Leben leichter zu machen, wenn sie auf ihrer Mailing-Liste und dem Bug-Tracker mit Hilfe von Hilferufen umgeht: Beachten Sie jedoch, dass wir zwar die Anstrengung freiwilliger Packager respektieren und ihre Zeit als kostbar, als ihre Zeit betrachten sollten Bequemlichkeit beim Debuggen ist nicht die einzige Art von Einfachheit, die Sie als Benutzer beeinträchtigt.

Homebrew tut diesbezüglich zumindest so, wie es früher getan wurde, und MacPorts versucht, nicht zu stören. Wenn Sie bereit sind, zu dokumentieren, welche Pakete Sie mit Homebrew benötigen, und wischen Sie / usr / local clean ab und installieren Sie das Programm im Falle von Schwierigkeiten neu, können Sie immer zurückkehren, falls etwas schief geht. Und wenn Sie feststellen, dass Probleme in / usr / local normalerweise nicht das Risiko einer dauerhaften Beschädigung Ihrer Maschinen bergen, fühlen Sie sich möglicherweise risikofreudiger.

Ich stelle nur fest, wie viel schlechter die Verpackung unter OSX ist als FreeBSD: Apple scheint sich nicht wirklich um die Verwendbarkeit seines BSD-Subsystems zu kümmern, da dies ein Problem ist, mit dem sie helfen könnten.

Nun, meine Frage wird aus der Perspektive eines dummen Benutzers gestellt, der nur den Paketmanager verwendet, um "Sachen zu bekommen". Es ist überhaupt nicht sicher, dass ich * in der Lage wäre, "Dinge etwas zu verstehen, wenn etwas schief geht." Trotzdem immer noch für die zusätzliche Klarstellung. Vielen Dank! Rich vor 13 Jahren 0
MacPorts ist ein guter Grund, / usr / local nicht zu verwenden, siehe http://trac.macports.org/wiki/FAQ#defaultprefix raimue vor 13 Jahren 1
@ Raim: Gute Gründe - es ist ein Kompromiss zwischen der Bequemlichkeit der Fehlersuche und der einfachen Installation auf dem Computer des Benutzers. Letzteres interessiert mich. Charles Stewart vor 13 Jahren 3
Die Anzahl der Dinge, die schief gehen können, weil jemand (oder etwas) eine Kopie von $ lib in `/ usr / local` installiert hat, ist endlos. Architekturen, Versionen, konfigurierte Funktionen und Flags, Teilinstallationen, veraltete Installationen mit Sicherheitsproblemen und und verursachen Probleme. Klar, machen Sie weiter, wenn Sie wissen, was Sie tun, aber melden Sie keine Fehler. Die Erfahrung zeigt, dass Leute sowieso Fehler einreichen, und das ist genau der Grund, warum der Trace-Modus (`-t`, siehe unten) existiert und warum die Vermeidung von` / usr / local` die Standardempfehlung ist. neverpanic vor 10 Jahren 0
@neverpanic - Meine Meinung zu den Risiken der Kompilierung von alles in / usr / local hat sich geändert, seit ich diese Antwort geschrieben habe, hauptsächlich weil die Komplexität beim Bauen komplexer Open-Source-Projekte immer größer wird und Autoconf-Probleme nicht einfacher werden sortieren: Zumindest ist "an Paranoiden grenzend" unfair. Ich mag den Ansatz von Macports "eigenes privates Build-Universum" immer noch nicht, und es verdient zu betonen, dass die Vereinfachung von Mailinglisten-Interaktionen nicht die einzige Art von Vereinfachung ist, um die sich der Endbenutzer sorgen sollte. Ich werde meiner Antwort Vorbehalte hinzufügen. Charles Stewart vor 10 Jahren 0
5
webappzero

Laut den MacPorts-FAQs :

Beachten Sie, dass MacPorts ab 2.3.0 automatisch / usr / local (und alle anderen Dateien, auf die ein Port nicht angewiesen ist) vor den Build-Systemen der Ports verbergen kann. Diese Funktion wird als Ablaufverfolgungsmodus bezeichnet und wird aktiviert, indem das Flag -t an port angegeben wird, z

sudo port -t install <portname>

Dies ist relevant, weil laut Homebrew-Installationsseite:

Einer der Gründe, warum Homebrew nur im Vergleich zur Konkurrenz funktioniert, ist, dass wir die Installation nach / usr / local empfehlen. Wählen Sie ein anderes Präfix an Ihrer Gefahr!

Daher kann ich mit wenig persönlicher Erfahrung theoretisch feststellen, dass die Verwendung der Option -t für MacPort-Installationen die meisten Probleme verhindern soll, wenn MacPorts und Homebrew auf demselben System koexistieren. Um Ihre letzte Frage zu beantworten: Ich sehe keinen Grund, warum die Deinstallation von MacPorts Probleme verursachen könnte.

Seien Sie sich bewusst, dass Sie unter einer erheblichen Leistungsstrafe leiden werden. Im Allgemeinen sollte dies jedoch in fast allen Fällen funktionieren. neverpanic vor 10 Jahren 0
Vielen Dank, dass Sie auf diesen Vorbehalt hingewiesen haben. Ich gehe davon aus, dass der Leistungsabfall nur die Installationszeit des Ports beeinflusst und keine Auswirkungen auf die Laufzeitmerkmale des installierten Ports hat. Wahr? webappzero vor 10 Jahren 0
Richtig. Es verhindert nur Build-Time-Probleme, nicht aber auch Laufzeitprobleme (diese sind jedoch sehr selten). neverpanic vor 10 Jahren 0
In der Praxis erinnerte ich mich nicht an diese Anforderung, das Trace-Flag immer zu verwenden. Daher empfehle ich diese Vorgehensweise nicht an andere, es sei denn, Sie sind überzeugt, dass Sie -t konsequent anwenden werden. webappzero vor 9 Jahren 0
Wenn Sie sich nicht daran erinnern möchten, können Sie ein Wrapper-Skript oder einen Shell-Alias ​​schreiben (achten Sie jedoch auf die Interaktion zwischen Sudo- und Shell-Aliasnamen), um es immer für Sie weiterzugeben. Beachten Sie, dass El Capitan derzeit den Trace-Modus unterbricht. Ich arbeite an einem Workaround. neverpanic vor 9 Jahren 0
4
plang

Bei der Installation von Homebrew auf einem Computer, auf dem ich seit Jahren Ports verwende, kann ich Folgendes lesen:

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

Achtung!

1
S. McCandlish

Die sudo port -t ...Lösung von webappzero sollte helfen. Um ehrlich zu sein, ich laufe mit Fink, MacPorts und Homebrew alle gleichzeitig, mit Respekt für MacPorts (vorerst sowieso) und nur eines der beiden anderen zum Installieren von Dingen, die ich nicht von MacPorts erhalten kann. Ich habe auf diese Weise nur sehr wenige Schwierigkeiten, noch bevor ich den port -tTrick gelernt habe . Wenn Sie versuchen, mehrere Paketmanager zur Verwaltung komplexer Entwicklungs- und Serverumgebungen zu verwenden, ist dies wahrscheinlich eine unangenehme Welt. Wählen Sie eine aus und vermeiden Sie die anderen, aber für etwas, das Sie dringend von ihnen benötigen, und setzen Sie die Hauptversion früher in den Pfad ein.

Wenn das, was ich höre, wahr ist, dass Apple verbietet, die Installation in / usr / anders als Apples eigenen zu installieren (oder vielleicht machen sie das schon in El Crapitan Probleme damit gelöst werden), nehme ich an, dass das Problem nach den Standardeinstellungen von Homebrew durch die Verwendung von etwas anderem gemildert wird - unabhängig davon, ob wir uns mit Apples hartnäckiger Vorgehensweise einig sind oder nicht.

Am Ende mag ich die Idee, Apples eigene Ports auf einen eigenen Baum zu beschränken. Ich wünschte nur, es wäre nicht / usr /. Ich hätte lieber, dass sie / System / bin usw. verwendet hätten, um ihre eigenen Sachen zu isolieren, damit ich sie mit aktueller, von der Community gewarteter Software leichter umgehen konnte.

Verwandte Probleme