Was sind die Vor- und Nachteile für MacPorts, Fink und Homebrew?


154

Ich migriere gerade von Ubuntu Linux auf Mac und alles ist neu und ich lerne eine Menge Dinge neu.

Unter Linux hatte ich die besten Voraussetzungen, um Softwarepakete zu verwalten. Ich habe auf dem Mac nach einer Alternative gegoogelt und bin auf MacPorts, Fink und Homebrew gestoßen.

Ich werde diesen Computer hauptsächlich zum Entwickeln von Ruby on Rails-Anwendungen verwenden.

Also, was sind die Unterschiede zwischen ihnen? Welches sind die Vor- und Nachteile? Welches ist am besten gewartet und hat mehr Pakete?


5
Ich habe Ihren Titel so bearbeitet, dass er zu Ihrer eigentlichen Frage passt. Auf den meisten Stack Exchange-Sites wird die Frage nach dem "Besten" verpönt.
Loïc Wolff

1
Warum brauchen Sie eines dieser Edelsteine, das nicht ausreicht?
user151019

Weitere Informationen darüber, warum Duplikate nicht immer schlecht sind: apple.stackexchange.com/questions/11461/… Außerdem gibt es dort noch ein paar Alternativen
cregox

Ich habe es nie benutzt, aber vielleicht wäre auch ein Vergleich mit pkgin nützlich.
Dennis

Antworten:


118

Auf jeden Fall Homebrew. Ich begann mit Fink, wechselte dann zu MacPorts (glücklicher) und dann zu Homebrew (viel, viel glücklicher). Dies sind meine Gründe für die Verwendung von jedem (eine Pro-Liste, wenn Sie so wollen):

Fink

  • Apt-basiert - fühlen Sie sich wie zu Hause, wenn Sie aus einer Debian-basierten Umgebung kommen
  • Binärpakete - Pakete sind als Binärdateien verfügbar, sodass keine langen Kompilierzeiten erforderlich sind. Praktischerweise habe ich festgestellt, dass die vorkompilierten Binärdateien immer veraltet waren und ich sowieso Sachen für mein System kompilieren musste
  • Gute Auswahl an Paketen

MacPorts

  • Größte Auswahl an Paketen / Ports
  • Im Allgemeinen sehr aktuell
  • Nettes Variantensystem , mit dem Sie den Build anpassen können
  • Einfache und intuitive Portdateien

Homebrew

  • Sehr aktuell
  • Maximale Ausnutzung des Lieferumfangs von OS X. Im Gegensatz zu Fink oder MacPorts müssen Sie Ruby und Bibliotheken nicht von Grund auf neu erstellen / installieren, um nur ein kleines Ruby-basiertes Tool zu installieren.
  • Bei der Installation in /usr/localmüssen Sie keine Änderungen PATHvornehmen
  • Da sich alles im Besitz des Benutzers befindet, benötigen keine Pakete für die Installation einen potenziell riskanten Root-Zugriff
  • Jedes installierte Paket befindet sich in einer sauberen Sandbox in einem eigenen Keller, sodass Sie nicht überall auf Ihrem System verirrte Dateien haben, sondern nur Symlinks von bin, man usw.
  • Lächerlich einfach , eigene Formeldateien ( zB Paketbeschreibungen) zu erstellen
  • Da Sie einen Ruby-Hintergrund haben, ist ein weiteres Plus, dass alles in Ruby geschrieben ist und alle Formeln einfache Ruby-Skripte sind

pkgin

  • Sehr aktuell
  • Schnellere Installationen durch vorkompilierte Binärdateien
  • Alles installiert in / opt / pkg /
  • unterstützt von pkgsrc community und Joyent
  • Bekannt für NetBSD, DragonFly BSD, Solaris, Debian, Mac OS X und Minix

https://pkgsrc.joyent.com/install-on-osx/

http://pkgin.net/


33
Beachten Sie, dass Sie für das Selbstbrauen argumentieren können, dass "Installationen in / usr / local" und "Nutzung von OS X" Probleme sind - dies sind die beiden Hauptgründe, warum ich ein anderes Verpackungssystem verwende
user151019

5
Angesichts der Tatsache, dass / usr / local / bin nicht im Standardpfad von Mac OS X enthalten ist, müssen Sie Ihren PFAD mit Sicherheit ändern - Sie müssen ihn nur einmal ausführen, da Brew an dieser Stelle Verknüpfungen zu allen neuen Pfaden erstellt Mülleimer installiert es (außer dem "Fass nur", aber das ist Lärm hier).
Terry N

5
@ jedd.ahyoung Ich bevorzuge Macports, die in / opt / local (Fink setzt in / sw)
user151019

5
Leider scheint Homebrew bestimmte Anwendungsfälle und APIs immer mehr abzulehnen, so dass die Betreuer eine offensichtliche Missachtung der Benutzer zum Ausdruck bringen . Macports scheint eine bessere Alternative zu sein, da dieser Trend beunruhigend für Homebrew zu sein scheint. Bei Homebrew ging es früher nur darum, dem Benutzer zu helfen, aber es hat sich langsam davon entfernt.
GDP2

5
Ich muss @ GDP2 zustimmen. Ich bin ein neuer Mac-Benutzer von Linux. Entwickler im Gebräu haben eine sehr schlechte Einstellung. Kannst du glauben, dass es nur 13 Probleme in brew's github gibt, wenn ich diesen Kommentar veröffentliche? Sie wollen den Nutzern nicht zuhören. Sie wollen keine Probleme. Sie ignorieren einfach alle Probleme, die Sie sofort geöffnet und geschlossen haben. Ich sehe nie eine solche Einstellung in irgendwelchen Github-Projekten. Als neuer Benutzer habe ich einige Monate lang Brew verwendet und heute denke ich, zu einem anderen zu wechseln, und habe diese Frage gefunden. Die Erfahrung mit dem Brauen ist die schlimmste, die ich bisher in meinem Leben hatte
sgon00

57

MacPorts

Es ist unabhängiger von Mac OS X, was bedeutet, dass MacPorts nur viele der in Mac OS X bereits verfügbaren Systembibliotheken und Softwareprogramme ignoriert und stattdessen eine eigene herunterlädt , was langsamer sein kann, wenn das von Ihnen installierte Dienstprogramm einige umfangreiche Pakete benötigt Bibliotheken und Software.

Aber diese Art der Wahl ist sicherer , weil die Pakete , die Sie weniger beeinflusst installiert werden von Apples System - Update / Upgrade - Verfahren.


Homebrew

Es hängt mehr von vorhandenen installierten Mac OS X-Paketen ab, wodurch die Installation von Paketen beschleunigt und redundante Bibliotheken minimiert werden.

Es besteht jedoch die Gefahr, dass installierte Pakete aufgrund der Systemaktualisierung / -aktualisierung von Apple beschädigt werden.

Das sind also die zwei verschiedenen Arten von Kompromissen.

Außerdem übernimmt Homebrew standardmäßig / usr / local , womit einige Leute nicht einverstanden sind, da dies in Konflikt mit der Unix-Tradition steht und Probleme verursachen kann, wenn Sie bereits etwas installiert haben (MySQL usw.).


Abgesehen von diesen Unterschieden können Sie in Anbetracht der Pakete, die diese beiden anbieten können, mit diesen beiden Befehlen prüfen, ob MacPorts / Homebrew bereits installiert ist. Diese zeigen Ihnen die Pakete, die sie derzeit bereitstellen:

port list | wc -l
brew search | wc -l

Und Sie werden feststellen, dass MacPorts viel mehr Pakete als Homebrew enthält.

(19399 vs 3583 am 13. Mai 2016)


17
Zu der unterschiedlichen Anzahl von Paketen: Homebrew enthält entschieden keine Pakete für Programmiersprachen, die ein eigenes Paketsystem haben (rubygems / pip / cpan ...) oder für Software, für die ein wohl geeigneteres OS X-Installationsprogramm verfügbar ist (MacTeX). . Außerdem sind Duplikate und ältere Versionen nicht im Standardrepo enthalten, sondern in alternativen Tap- Repos. Vergleichen Sie dies mit macports, die z. B. einen IPython-Port für alle enthaltenen Python-Versionen enthalten. Es ist eine andere Philosophie, die natürlich die Anzahl der Pakete in Macports erhöht.
Debilski


@YaOz, Sicherlich könntest du Homebrew ändern, um etwas anderes als zu verwenden /usr/local?
Pacerier

41

Um nur einige meiner eigenen Gedanken hinzuzufügen, die mindestens Ende 2014 zutreffend zu sein scheinen.

Homebrew hat seit ein paar Jahren definitiv die Oberhand in Sachen Mindshare. Es gibt eine Menge Blogs, in denen Leute darüber reden, wie viel glücklicher sie mit Homebrew sind - normalerweise wegen der ganzen "MacPorts zieht in der ganzen Welt" gegen "Homebrew nutzt, was Sie bereits haben".

Allerdings, IMO, ist MacPorts jetzt ein anderes Biest als vor ein paar Jahren. Als ich zum ersten Mal auf OS X & MacPorts umstieg, war die MP-Philosophie in der Tat frustrierend, da fast alles aus dem Quellcode erstellt wurde. Eine Neuinstallation war besonders schmerzhaft / langsam. Im letzten Jahr schienen jedoch 90% der MP-Pakete Binärdateien zu sein, und die Installation ist jetzt wirklich sehr schnell. Aus dem, was ich erfahre, bewegt sich Homebrew mit "Bottles" ebenfalls in diese Richtung, aber ich habe den Eindruck, dass die meisten Dinge, die Sie zu diesem Zeitpunkt über HB installieren, aus dem Quellcode kompiliert werden.

Wenn man nur eine gegenläufige Meinung äußert, scheint MacPorts heutzutage die "schnellere" Option zu sein. Allerdings scheinen die meisten Völker Meinungen von MP auf Erfahrungen von ca. 2011-12 zu beruhen und berücksichtigen dies nicht wirklich. Nehmen Sie dies mit einem Körnchen Salz, da ich kein regelmäßiger HB-Benutzer bin (und es ziemlich schmerzhaft ist, beide nebeneinander zu verwenden).

Ich denke, HB hat Vorteile, die bedeuten, dass es auf lange Sicht wahrscheinlich "den Krieg gewinnen" wird

  • HB ist alles Ruby, während MacPorts und seine Paketformeln in TCL geschrieben sind, einer nicht gerade beliebten Skriptsprache. Das heißt, es ist verdammt einfach, ein eigenes Portfile zu erstellen.
  • HB basiert auf GitHub und scheint daher neue Mitwirkende viel willkommener zu finden, während MacPorts, glaube ich, irgendwo sein eigenes SVN-Repository hostet - was im Grunde genommen das unterschiedliche Alter beider Projekte widerspiegelt, nehme ich an.
  • Wie bereits erwähnt, herrscht allgemeiner Konsens darüber, dass MacPorts von HB abgelöst wurde und dass dies zu Recht oder zu Unrecht mehr Menschen anzieht.

Ansonsten deckte YaOZl & kLy den Hauptunterschied in Bezug auf Sudo, Abhängigkeiten usw. ziemlich gut ab. Persönlich stelle ich fest, dass MacPorts manchmal zu Kopfschmerzen in Bezug auf andere Programme führt, die nicht erwarten, dass irgendetwas enthalten ist /opt/local, Dinge mit Root-Rechten installiert werden usw. & es gibt einige Dinge, die im Allgemeinen am besten nicht mit MacPorts installiert werden können (z. B. können Sie Rails über installieren) MacPorts, aber Sie wären verrückt, wenn Sie es nicht über Rubys normale Gem-Verwaltung installieren würden. Abgesehen davon bin ich ein großer Fan der MacPorts-Philosophie, eine eigene kleine Welt aufzubauen und mich nicht auf eine vorgefertigte OS X-Bibliothek zu verlassen - wenn sie funktioniert und meistens funktioniert, ist alles denkbar einfach. Welches ist, was Sie von einem Paket-Manager wirklich wollen. Und wie gesagt, zu diesem Zeitpunkt ist es verdammt schnell, die meisten Dinge einzurichten.

Hoffe, dass etwas davon nützlich war.


"Wie bereits erwähnt, herrscht allgemeiner Konsens darüber, dass MacPorts von HB abgelöst wurde und dass dies zu Recht oder zu Unrecht mehr Menschen anzieht." ... das fühlt sich wie eine sehr oberflächliche Aussage an ... populär zu sein und Qualität zu liefern, ist nicht dasselbe und bedeutet keineswegs, dass die zweite durch die erste "ersetzt" wird.
Dmitri Zaitsev

3

Brew war für mich völlig flüssig, daher kann ich nichts über seine Nachteile sagen. Einige Nachteile von MacPorts:

Zu den ersten beiden Punkten gibt es einige sehr beliebte Fragen.


Dies war meine Erfahrung mit der Installation von ImageMagick auf 10.6. Das Brauen war sehr einfach, aber ohne den JP2-Delegierten. imagemagick.org/script/binary-releases.php
Nemo

2
Brew und Macports benötigen nur Xcode-Kommandozeilen-Tools.
user151019

@Mark Ich bin mir nicht sicher, was du meinst, aber das Brauen hat bei mir ohne Xcode perfekt funktioniert.
Nemo

2
Sie benötigen einen Compiler für Brew und MacPorts, der über die Xcode Command Line Tools installiert werden kann. Sie benötigen die Xcode- Anwendung nicht .
Nohillside

1
Ich habe vergessen, wie hässlich es ist, das Ding hinter einer Firewall zu synchronisieren ... igitt!
Rogerdpack
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.