Sachen installieren: Brew vs. offizieller Installer – welcher sollte verwendet werden?

Es gibt eine ähnliche Frage hier auf Ask Different - Was sind Vor- und Nachteile für MacPorts, Fink und Homebrew? - das macht einen Vergleich der verschiedenen Paketmanager. Es ist eine ausgezeichnete Lektüre und ich ermutige Sie, es zu überprüfen.

Sollte ich Homebrew oder das offizielle Installationsprogramm verwenden? Warum?

Der Hauptunterschied zwischen der Verwendung von Homebrew und der Verwendung des Installationspakets sind die Abhängigkeiten von der Erstellungszeit. Homebrew (und MacPorts) leisten hervorragende Arbeit bei der Verwaltung all dessen. Mit dem Paket gibt es jedoch keine Build-Anforderungen und die Software ist einsatzbereit.

Deinstallieren ist kaum noch ein Problem. Homebrew verwaltet den Deinstallationsprozess und behandelt die Laufzeitabhängigkeiten, indem es sie bei Bedarf kürzt. Mit kostenlosen Apps wie AppCleaner ist das gründliche Entfernen einer App jedoch kein Problem.

Unterm Strich kommt es also auf Ihren Workflow an. Wenn Sie einfach nur ein Dienstprogramm benötigen, laden Sie das Paket herunter. Wenn Sie mehr als eine verwenden und es gemeinsame Bibliotheken gibt, die Sie verwalten möchten, entscheiden Sie sich für Homebrew.

Wie kann ich mein System von der Verwendung der /usr/local/bin Node-Installation auf die /usr/local/Cellar-Installation umstellen?

Du änderst deinen Weg.

Abhängig von Ihrer Shell ( ~/.bash_profilefür Bash und ~/.zprofilefür Zsh) fügen Sie lediglich das Verzeichnis des neuen Dienstprogramms hinzu (siehe ZSH: .zprofile, .zshrc, .zlogin - Was gehört wohin? für weitere Informationen). Um sicherzustellen, dass es vor der anderen (nativen) Anwendung ausgewählt wird , setzen Sie es zuerst in die Pfadvariable. Der Standardpfad ist beispielsweise (festgelegt durch path_helper)

/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

Fügen Sie in Ihrem Profil einfach die Zeile hinzu, wo sich Ihre Binärdateien befinden. Verwenden Sie Ihr Beispiel, um Ihren Pfad hinzuzufügen:

PATH=/usr/local/Cellar:$PATH

Ihrem neuen Pfad wird Ihr Cellar-Verzeichnis dem vorhandenen vorangestellt. Da es Ihrem vorhandenen Pfad vorangestellt ist (kommt), wird es zuerst in diesem Verzeichnis suchen. Ausführliche Informationen finden Sie in der Homebrew-Dokumentation . Ich persönlich verwende eine Kombination aus MacPorts und "offiziellen" Installern, also verwende ich eine andere Verzeichnisstruktur. YMMV.

Sollte ich Homebrew oder das offizielle Installationsprogramm verwenden? Warum?

Ich bevorzuge immer einen Paketmanager wie brew oder conda gegenüber .pkg-Dateien, die keine Deinstallationsprogramme bereitstellen.

• Man kann überprüfen, welche Abhängigkeiten installiert werden.
• Einfache Reinigung.
• Sie müssen sich nicht merken, ob etwas mit der Standardinstallation von macOS geliefert oder später installiert wurde.
• Root-Passwort muss nicht eingegeben werden.

Tools, die nicht auf brew zu finden sind und die ich selbst baue, werden mit gebaut CMAKE_INSTALL_PREFIXund in installiert ~/Applications. Binärdateien, die ich direkt von irgendwo herunterlade, werden ebenfalls aufbewahrt~/Applications

Dann füge ich den Installationspfad zu PATHby hinzu ~/.bash_profile.

brew behält die eigentlichen Binärdateien oder Bibliotheken in /usr/local/Cellar/<package>/<version>/binund erstellt einen Alias ​​in /usr/local/binoder /usr/local/liboder include. Und fügt den Pfad /usr/local/binin Ihre PATHVariable ein.

Hier ist also eindeutig die offizielle Installation zu bevorzugen (vielleicht weil ich sie zuerst installiert habe? Ich weiß es nicht)

Nein, es ist der Vorrang. In PATHVariable wird standardmäßig /usr/local/binzuvor erwähnt . /usr/bin(Siehe die install.sh- Datei). Wenn also eine Binärdatei gefunden wird, werden die nächsten Standorte nicht überprüft.

Was Sie von der Website heruntergeladen haben, ist vereinfacht

curl "https://nodejs.org/dist/latest/node-${VERSION:-$(wget -qO- https://nodejs.org/dist/latest/ | sed -nE 's|.*>node-(.*)\.pkg</a>.*|\1|p')}.pkg" \
> "$HOME/Downloads/node-latest.pkg" \
&& sudo installer -store -pkg "$HOME/Downloads/node-latest.pkg" -target "/"

Ich vermute, das nodeist installiert in /usr/bin.

Also, um die Dinge aufzuräumen,

• Laufenbrew uninstall node
• Holen Sie sich die xz-Datei von https://nodejs.org/dist/latest/ und überprüfen Sie ihren Inhalt.
• Suchen Sie nacheinander alle Ordner und Dateien wie README und Changelog, die mit dem heruntergeladenen xz übereinstimmen, und löschen Sie sie. Höchstwahrscheinlich sind sie unter zu finden /usr/bin. /usr/local/binWas hier helfen würde, ist die Verwendung des Finder und die Sortierung nach "Datum hinzugefügt".
• brew install node.

Wie kann ich mein System von der Verwendung der /usr/local/bin Node-Installation auf die /usr/local/Cellar-Installation umstellen?

Nachdem Sie die obigen Schritte ausgeführt haben und die Brew-Installation korrekt ist, dh echo $PATHenthält /usr/local/bin, müssen Sie nichts weiter tun.

Wenn Sie vorhaben, viele Dinge zu installieren, ist ein Paketmanager möglicherweise nützlicher. Wenn Sie nur eine Handvoll Dinge installieren müssen, die ihre eigenen Installer haben und für die die Aktualisierung einfach ist, kann die Installation von etwas wie HomeBrew nur eine weitere Ebene der Komplexität hinzufügen.

Es gibt auch Auswirkungen auf die Sicherheit, wenn man alle Eier in einen Korb legt. https://medium.com/@vesirin/how-i-gained-commit-access-to-homebrew-in-30-minutes-2ae314df03ab

Zu Ihrer ersten Frage Soll ich Homebrew oder das offizielle Installationsprogramm verwenden? Ich habe das Bedürfnis, einen Nachteil der Verwendung von Homebrew hinzuzufügen, den ich hier oder in der anderen Frage nicht gesehen habe : Langzeitkompatibilität.

Nehmen Sie zum Beispiel El Capitan, das auf Macs installiert ist, die nicht weiter aktualisiert werden können. Während diese Macs immer noch gut funktionieren, hat Homebrew (als Apple) die Unterstützung für diese Betriebssystemversion eingestellt . Wenn Sie jetzt etwas auf El Capitan versuchen, brew installfunktioniert es möglicherweise, es kann fehlschlagen, oder es kann eine langwierige Kompilierungsprozedur starten und dann fehlschlagen.

Ich fand, dass es sich nicht lohnt, diesen Prozess jedes Mal auszuprobieren, also installiere ich jetzt auf der alten Maschine alles mit dem offiziellen Installationsprogramm.

Ich frage mich, wie Programme auf dem Mac installiert werden sollen. Über Homebrew oder einen offiziellen Installer, falls vorhanden?

Andere Antworten hier haben verschiedene Besonderheiten angesprochen. Ich werde meine Antwort auf diese Frage beschränken, einige Empfehlungen geben und sie kurz erläutern.

Rolle eines Paketmanagers in macOS

Ich denke, dass die meisten Benutzer der verschiedenen Linux- und BSD-Distributionen die Bedeutung eines guten Paketmanagers zu schätzen gelernt haben. Ich verwende hauptsächlich Debian-basierte Distributionen und halte den Paketmanager ( aptitude) für ebenso wichtig wie den Kernel selbst. Damit meine ich, wenn der Paketmanager nicht existierte oder unzuverlässig und fehleranfällig wäre, dann wäre ich kein Linux-Benutzer.

Apple hat sich entschieden, per se keinen Paketmanager bereitzustellen . Apple stellt eine Auswahl an Open-Source- Tools bereit – sie sind mit der macOS-Distribution gebündelt und werden nach Apples Ermessen aktualisiert. Aber es gibt eine riesige Welt von Open-Source-Software ; Vieles davon ist von ausgezeichneter Qualität und bietet wesentliche Vorteile gegenüber Closed-Source-Software .

Für mehr als 2-3 Pakete sind die meisten Benutzer meiner Meinung nach am besten mit einem Paketmanager bedient . Einige Pakete unterstützen die eigenständige Installation unter macOS sehr gut. Einige unterstützen sogar Updates und einige unterstützen auch das Entfernen. Dies sind jedoch zwangsläufig unterschiedliche, paketspezifische Verfahren, und die Wartung wird zu einer zeitaufwändigen Aufgabe.

Vergleich von Paketmanagern, die unter macOS weit verbreitet sind

Ich glaube, dass unter macOS drei Paketmanager weit verbreitet sind:

• Hausgemacht
• MacPorts
• git

gitEinige werden meiner Bezeichnung als Paketmanager widersprechen . Ich werde nicht behaupten, dass dies streng genommen Versionskontrollsoftwaregit ist , aber ich habe das Gefühl, dass die Unterschiede in obskurem Jargon zu verschwinden scheinen, wenn sie mit riesigen Sammlungen von kostenlosen und Open-Source-Repositories gekoppelt sind .git

Ich habe Homebrew vor einigen Jahren ausprobiert, und die meisten meiner Meinungen sind durch diese Erfahrung entstanden. Einfach gesagt, trotz der Tatsache, dass ich einige Erfahrung mit Paketmanagern hatte, als ich Homebrew zum ersten Mal ausprobierte , fand ich es umständlich und unzuverlässig. Verpackungsstandorte, "immer wieder Verwendung von sudo" , Jargon, der sich auf die Bierherstellung bezog: "brew = make ?" , was ist ein "Fass" ? und die Verwendung von Ruby (was großartig ist, wenn Sie ein Benutzer sind, aber ich nicht) haben alle zu seiner mangelnden Attraktivität beigetragen. Aber einige lieben es, und für diese Leute sage ich nur: "Party on, Garth"!

Kurz darauf beschließe ich, MacPorts auszuprobieren, und seitdem benutze ich es. Ich denke, das liegt vor allem daran, dass es mir rational, unkompliziert und einfach zu bedienen erscheint. Es bietet viel Tiefe für ungewöhnliche Situationen, die von Zeit zu Zeit auftreten, aber um damit produktiv zu werden, sind nur wenige Minuten und eine Handvoll Befehle erforderlich. Kenntnisse können in wenigen Stunden erreicht werden. Zusammenfassend ist MacPorts meine uneingeschränkte Empfehlung für einen reinen Paketmanager.

Ein paar Worte über gitund warum ich denke, dass es ein nützlicher "Paketmanager" ist . Als Versionskontrolltool gitist es ein komplexes Stück Software, dessen Beherrschung viel Aufwand erfordert. Sie können sich ein Bild davon machen, indem Sie die vielen manSeiten für git, und seine verschiedenen Tochterunternehmen lesen. Die Verwendung zum „Installieren“ und Aktualisieren von Paketen, die in einem gitRepository ( z. B. GitHub ) gehostet werden, erfordert jedoch nur wenige Befehle. Ich denke, es ist hauptsächlich in zwei Situationen nützlich:

1. Für Pakete (Skript, Dokumentation usw.), die nicht auf MacPorts verfügbar sind
2. Pakete, für die Sie Codierungsänderungen vornehmen und selbst kompilieren möchten

Aus Sicherheitsgründen tendiere ich eher zu Macports/Homebrew als zu offiziellen Installern.

Es gab eine Reihe von Vorfällen, bei denen die Server von Softwareanbietern/-anbietern kompromittiert und Malware in die Downloads eingeschleust wurde.

Dies kann sehr wahrscheinlich auch auf Macports/Homebrew passieren, aber der Unterschied besteht hauptsächlich darin, dass die Leute, die sich um diese Repositories kümmern, ständig bösartiges Verhalten erwarten und von ihnen erwartet werden kann, dass sie über ein gewisses Fachwissen verfügen, um die bösen Jungs zu stoppen. Auch viele Augäpfel. Wenn es noch schlimmer wird, wird wahrscheinlich jemand anderes vor mir Probleme mit Macports/Homebrew haben, aufgrund des hohen Verkehrsaufkommens.

Wohingegen ein Unternehmen/Entwickler, der in erster Linie ein Softwarepaket schreibt, in erster Linie Erfahrung im Schreiben seiner Software haben wird, anstatt seine Download-Server zu sichern. Nun, die meisten von ihnen machen wahrscheinlich trotzdem einen sehr guten Job, aber Sie müssen sich darauf verlassen, dass alle es richtig machen, anstatt nur 1-2, Macports und Homebrew. Einmal kompromittiert, könnte es eine Weile so bleiben, bevor die Leute es bemerken.

Sie können auch schnell eine Art von port outdatedBericht ausführen, um festzustellen, was gepatcht werden muss.

Letztendlich gehen Sie jedes Mal, wenn Sie etwas installieren, ein gewisses Risiko ein. @benwiggys Vorsichtswort ist hier absolut zutreffend.

Es kommt darauf an, dass ich keine Antwort geben würde, außer Homebrew und individuelle Installationen nicht zu mischen.

Wenn Sie jedoch Homebrew verwenden, können Sie keine offiziellen Installationsprogramme für Fälle wie Knoten verwenden. Dies liegt daran, dass sowohl Homebrew als auch Node /usr/local verwenden möchten, was der häufigste Ort ist, um Software von Drittanbietern unter Unix-ähnlichen Betriebssystemen zu installieren. Die Stand-Build-Software, z. B. die Auto-Tools von GNU, wird standardmäßig dort installiert, sodass die meisten Installer sie dort einfügen. Wenn Sie Software von Drittanbietern in diesem Verzeichnis installiert haben, kann Homebrew verwirrt werden, siehe Fragen hier mit der Ausgabe von Brew Doctor.

Andere Paketmanager werden in anderen Verzeichnissen installiert, sodass sie /usr//local für Ihre Verwendung zulassen. Macports verwendet standardmäßig /opt, kann aber auch andere Verzeichnisse verwenden. Fink verwendet /sw