Können pkgsrc, Homebrew, Fink und MacPorts friedlich nebeneinander bestehen?

2920
hpy

Ich habe gehört, dass manche Leute sowohl Fink als auch Macports verwenden, da einige Pakete in einem und nicht in dem anderen existieren.

Ich hatte kürzlich Probleme beim Erstellen und Ausführen von Paketen wie GRASS und Digikam w / MacPorts und habe nach Alternativen gesucht.

Ich frage mich nur: Würden Pkgsrc und Homebrew auch koexistieren und gut mit ihnen funktionieren?

Ich probiere noch Paketmanager aus und erkunde gerne alle Möglichkeiten, bevor ich mich für ein oder zwei entscheiden kann.

Vielen Dank!

6

2 Antworten auf die Frage

7
raimue

Homebrew verursacht Probleme beim Erstellen von Software aus der Quelle, wenn diese in installiert wird /usr/local. 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, wurde sogar MacPorts verwendet /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 tut alles, um harcodierte Pfade zu patchen, zu /swdenen zB Fink führt. Normalerweise wird es funktionieren, aber alles installiert zu haben, /usr/localwird definitiv Probleme verursachen.

Ich kenne pkgsrc nicht genug, um zu sagen, ob es wirklich auf die gleiche Weise betroffen ist, aber ich schätze, dass dieses Problem auch für dieses Problem gilt.

Es scheint keine offenen Fehler für Digikam oder Gras in MacPorts zu geben. Sie sollten Ihre Probleme direkt mit neuen Tickets melden, um Hilfe zu erhalten.

Bei Homebrew sollten Bibliotheken und Programme * installiert werden, die nicht in OS X enthalten sind. MacPorts hat `/ usr / local` nicht gern verwendet, da MacPorts viele doppelte Bibliotheken installiert, die bereits in OS X enthalten sind und nicht möchte mit seltsamen Dingen umgehen müssen, wenn Benutzer dieselbe Bibliothek in `/ usr / local` installiert haben. Es wollte auch sein gesamtes System von allem anderen isolieren. MacPorts und Homebrew haben diesbezüglich unterschiedliche Philosophien. Zu sagen, dass Homebrew schlecht ist, weil Software in "/ usr / local" installiert wird, ist so etwas zu sagen: "/ usr / local" sollte nicht verwendet werden *, was dumm ist. mipadi vor 13 Jahren 2
Nein, am Anfang verwendete MacPorts-Systembibliotheken. Dies war jedoch nicht wartbar, während mehrere Versionen von OS X unterstützt wurden. Daher wurde die Richtlinie so geändert, dass sie nur auf eigene Bibliotheken basiert. Der Rat, `/ usr / local` nicht zu verwenden, wenn Sie auch MacPorts verwenden, ist absolut sinnvoll. Der Pfad befindet sich im Standardsuchpfad von Compilern und kann nicht entfernt werden. raimue vor 13 Jahren 3
Richten MacPorts nicht trotzdem eigene Suchpfade ein und ignorieren `/ usr` und` / usr / local`? Bei der Suche nach Bibliotheken sucht MacPorts offensichtlich nicht nach "/ usr", da es ohnehin seine eigenen Kopien installiert. mipadi vor 13 Jahren 0
Es ist unmöglich, / usr und / usr / local zu ignorieren. Diese Suchpfade sind im Compiler fest codiert. raimue vor 13 Jahren 1
Okay, ich sollte das anders formulieren: MacPorts prüfen nicht zuerst ihren eigenen Baum? (Andernfalls ist es nicht sinnvoll, Bibliotheken zu duplizieren.) Andererseits ist es wichtig zu wissen, dass Homebrew keine doppelten Bibliotheken _at all_ installiert. Es wird nicht einmal eine doppelte Version von Autoconf installiert. Wenn für eine bestimmte Formel eine neuere Version einer doppelten Bibliothek erforderlich ist, wird sie im "Keg-Only" -Modus installiert, das heißt, sie wird in `/ usr / local / Cellar` anstelle von` / usr / local / gespeichert. lib`. Homebrew ist sehr vorsichtig, wenn Sie keine Elemente installieren, die manuelle Zusammenstellungen beschädigen könnten. mipadi vor 13 Jahren 1
* Es ist unmöglich, / usr und / usr / local zu ignorieren * - dies sind Standardeinstellungen, die mit Optionen überschrieben werden. @mipadi hat recht. Charles Stewart vor 13 Jahren 0
Nein, sie können nicht überschrieben werden. Sie können andere Pfade voranstellen, diese befinden sich jedoch immer am Ende des Suchpfads. Wenn Sie das nicht verstehen, sollten Sie erkennen, wie komplex das Problem ist, und entweder tiefer eintauchen oder uns einfach vertrauen. raimue vor 13 Jahren 4
Raim: Sie können Personen über Ihre Antworten benachrichtigen, indem Sie genügend @ mit einem vorangestellten Namen versehen, also @Charles. LDFLAGS = -Z löscht / usr und / usr / lib von den ld-Standardeinstellungen, obwohl ich sehe, dass Sie recht haben - einige Macports-Pakete werden diese unerklärlicherweise wieder in ihren Suchpfad einfügen: https: //trac.macports .org / ticket / 23400 (siehe Aufruf von gcc). Wenn ich mich für Macports interessiere, würde ich dies als Fehler melden, aber ich füge dies einfach der Liste der Gründe hinzu, warum ich Macports weniger erträglich finde als Homebrew und Fink. Charles Stewart vor 12 Jahren 0
1
GDP2

Es stimmt, das Mischen von Paketmanagern kann Kopfschmerzen verursachen. Aber ich benutze sowohl Homebrew als auch MacPorts und es funktioniert, weil ich ein paar Pakete in Homebrew habe. Die einzigen Dinge, die ich habe, sind Endbenutzerprogramme, die (noch) nicht in MacPorts verfügbar sind. Zum Beispiel: gist, dashing, und sqldiff. Wenn Sie den einen oder anderen Paketmanager auf ein Minimum beschränken, werden die Kopfschmerzen weniger wahrscheinlich.

Der einzige Grund dafür ist jedoch, wenn Sie ein Paket benötigen, das in einem bestimmten Paketmanager nicht verfügbar ist. Persönlich habe ich herausgefunden, dass MacPorts die überwiegende Mehrheit der Programme hat, die ich brauche, und es ist viel reifer als Homebrew in vielerlei Hinsicht. Es ist auch einfacher, dazu beizutragen, mit weniger strengen Regeln und einer schönen Skriptsprache (Tcl, was wirklich so schön ist wie Ruby). Es gibt viele andere Vorteile von MacPorts gegenüber Homebrew, aber ich mache weiter und beende meine Tangente hier.

Verwandte Probleme