Homebrew 6.0.0 veröffentlicht

• Die interne JSON-API, die alle Metadaten in einem einzigen Download bündelt, ist jetzt der Standard, wodurch Updates beschleunigt und die Netzwerkkommunikation reduziert werden
  • Die bisherige Opt-in-Variable HOMEBREW_USE_INTERNAL_API ist als deprecated markiert
• Unter Linux wird die Bubblewrap-Sandbox angewendet, sodass die Schritte build, test und postinstall wie unter macOS isoliert ausgeführt werden
• Auf Basis einer Nutzerumfrage wird der ask-Modus zum Standard für Entwickler; bei brew install und brew upgrade werden eine Abhängigkeitszusammenfassung und eine Bestätigungsabfrage angezeigt
• In brew bundle wird die parallele Installation von Formulae standardmäßig automatisch ausgeführt; außerdem kommen Erweiterungen für npm und krew sowie Unterstützung für Windows-winget hinzu
• Leistungsverbesserungen im gesamten Start- und Upgrade-Prozess, darunter rund 30 % Beschleunigung bei brew leaves
• Frühe Unterstützung für macOS 27 (Golden Gate) hinzugefügt
  • Mit dem Ende der Intel-Unterstützung wird macOS Intel x86_64 ab September 2026 zu Tier 3 und ab September 2027 vollständig nicht mehr unterstützt
• Drei Sicherheitshinweise veröffentlicht und behoben (Umgehung von HTTPS→HTTP-Redirects, Root-Codeausführung im .pkg-postinstall, Übernahme des plist-Besitzes unter /var/tmp)
• Neue Befehle wie das an npx angelehnte brew exec sowie brew vulns zur Prüfung installierter Pakete auf Schwachstellen hinzugefügt
• Einführung eines Install-Steps-Frameworks, das gemeinsame postinstall- und flight-Abläufe als wörtliche DSL-Daten über die JSON-API bereitstellt, sodass bei einfachen Aufgaben keine Ruby-Dateien mehr heruntergeladen und ausgewertet werden müssen
• Für risikoreiche Ökosysteme wie npm und PyPI wird ein Download-Cooldown angewendet, um Sicherheitsrisiken in der Upstream-Lieferkette zu mindern

[lamanus]

Es fehlen die Ressourcen, um sogar Intel-Macs weiter zu unterstützen, und da GitHub Actions künftig ebenfalls keine Images mehr bereitstellen wird, bleibt Homebrew nichts anderes übrig, als sich daran anzupassen.

[GN⁺]

Hacker-News-Kommentare

• Ich bin @bfontaine von GitHub. Ich habe etwa 2014–2016 bei der Wartung von Homebrew geholfen, und es erstaunt mich immer wieder, dass Mike es seit über 16 Jahren weiter pflegt und noch immer neue Features veröffentlicht

  • Im September werden es 17 Jahre. Danke für deine großartigen Beiträge damals, und ich hoffe, dir geht es gut
  • Homebrew ist so gut, dass ich es nach Möglichkeit auch unter Linux nutze
    Die meisten Linux-Paketmanager können von Nutzern installierte Pakete nicht von Systempaketen trennen, wodurch es fast unmöglich wird, eine Workstation aufzuräumen, und schwer zu beurteilen ist, was man gefahrlos löschen kann
    Außerdem aktualisieren native Paketmanager oft langsamer als Homebrew, sodass man häufig nur veraltete Pakete bekommt

• Aus Experimentierfreude habe ich meine komplette Entwicklungsumgebung auf OS-Ebene von Homebrew+pipx+npm auf https://mise.jdx.dev/ umgestellt, und in der Praxis funktioniert das sehr gut
  Viele Tools werden direkt aus GitHub-Releases oder den entsprechenden Paketmanagern (uv, pnpm, go get usw.) installiert, sodass weder Klebecode fürs Repackaging noch Versionsverzögerungen entstehen
  Man kann beliebige Versionen oder mehrere Versionen gleichzeitig installieren und die aktive Version dynamisch pro Arbeitsverzeichnis oder Umgebung umschalten
  Interessanterweise unterstützt Mise keine Abhängigkeiten, aber das war meist kein Problem. Entweder übernehmen pnpm/uv das oder es sind statische Binärdateien und es funktioniert einfach
  Früher habe ich einmal eine Python-App für Homebrew paketiert, dabei 50 Abhängigkeiten als resources eingebunden, alles entweder aus dem Quellcode gebaut oder manuell geprüft, ob es in Homebrew vorhanden ist, Build-Toolchains aus 5 Sprachen als Abhängigkeiten deklariert und bei jedem Update über eine Stunde auf CI gewartet, bis ein Upstream-Update schließlich eine „Build-Time-Dependency-Loop“ erzeugte, die sich in Homebrew nicht mehr auflösen ließ
  Deshalb verstehe ich vollkommen, warum Mise den „einfachen Weg“ wählt und sich direkt auf sprachspezifische Paketmanager stützt
  Das Einzige, was ich nicht aus der Brewfile ersetzen konnte, war die Docker-CLI, die für die Kommunikation mit Colima nötig ist, und für Casks nutze ich weiterhin Homebrew. Ich kann nur empfehlen, mit Entwicklungsumgebungen zu experimentieren. Es gibt heutzutage viele großartige neue Tools

  • Mise scheint definitiv in einer eigenen Liga zu spielen. Wie ich auch anderswo gesagt habe, stützt es sich auf Registries wie aqua oder asdf
    Für Leute, die Mise für Homebrew-Pakete verwenden möchten, gibt es https://github.com/kennyg/mise-zerobrew
  • Als PHP-Entwickler war die Unterstützung von Mise ziemlich deutlich schwächer als das PHP-Packaging, das Shivam Mathur für Homebrew gemacht hat
    Die meisten Projekte verwenden ohnehin Docker, und lokales PHP ist eher für Dinge wie statische Analyse gedacht, bei denen Docker nicht nötig ist
    Ich habe auch ein paar Projekte, die Nix nutzen; Nix stellt zwar alles andere in den Schatten, aber die gesamte User Experience ist noch feindseliger als git
  • Schön, dass du gute Erfahrungen gemacht hast, aber ich persönlich bin von Mise zurück zu Brew gewechselt
    Das mag an meinen Fähigkeiten gelegen haben, aber es gab in Mise einfach zu viele Pakete, bei denen Probleme auftraten
  • Ich mag Mise sehr, nutze es aber nur für projektbezogene Tool-Verwaltung oder Dinge wie JDK-Versionen
    Ich habe es auch für systemweite Tools ausprobiert, aber für Dinge wie Helix, NeoVim oder RipGrep, bei denen ungefähr die aktuelle Version reicht und die genaue Versionsnummer egal ist, war es nicht so passend
  • Mise unterstützt Abhängigkeiten durchaus in gewissem Maß, aber nicht in der Weise, wie man es von anderen Paketmanagern erwarten würde
    Abhängigkeiten in Mise sind nicht automatisch, sondern müssen alle manuell definiert werden. Das dient dazu, Reihenfolgeprobleme durch parallele Installationen zu vermeiden. Wenn man zum Beispiel pipx:black verwendet, muss gewartet werden, bis Python installiert ist. Dafür gibt es die depends-Option des Tools
    Das ist so beabsichtigt. Mise ist nicht als vollständige Bootstrap-Lösung wie Homebrew oder Nix konzipiert, sondern als Overlay auf einem bestehenden System
    Deshalb kann man Python mit Brew verwalten und black mit Mise, und es funktioniert fast sofort ohne zusätzliche Konfiguration. Ich halte diese Designentscheidung für einen großen Erfolg. Es klingt wie ein Nachteil, ist am Ende aber wahrscheinlich der Hauptgrund, warum Nutzer Mise als so unkompliziert empfinden

• Homebrew war ein großartiger Weg, Umgebungen auf unveränderlichen Linux-Distributionen schnell zu bootstrappen
  Es sind nicht viele Nutzer, aber laut https://formulae.brew.sh/analytics/os-version/365d/ liefern Betriebssysteme wie Bazzite (1,28 %), Bluefin (0,49 %) und Aurora (0,28 %) von Universal Blue Homebrew standardmäßig mit aus
  Das zugehörige Repository ist https://github.com/ublue-os/brew

  • Das Konzept eines Paketmanagers im User Space wirkt wie etwas, das Linux schon vor 20 Jahren hätte lösen sollen
    Dass die normale Situation für Nicht-Root-Nutzer lautet: „Du kannst XY nicht installieren, aber aus dem Quellcode bauen darfst du gern“, ist schon absurd
    Homebrew, Mise und Nix füllen diese Lücke heute. Flatpak ist eher für GUI-Apps, und Snap … existiert auch
  • Ich nutze unter Bazzite Nix zusammen mit home-manager

• Die ersten drei Dinge, die ich installiere, sind Sublime Text, Homebrew und die neueste Bash. Ich habe nicht vor, zu Zsh zu wechseln
  Gute Tools machen Computing angenehm

  • Man kann erst Homebrew installieren und dann damit Sublime und Bash

• Ich bin vor Kurzem von Nix zurück zu Homebrew gewechselt, und dafür gibt es im Wesentlichen drei Gründe
  Brew scheint die von mir genutzten Pakete besser zu unterstützen als Nix. Bei Nix wirken einige Pakete so, als würden sie nicht besonders gut gepflegt
  Auch die Mac-Unterstützung ist besser. Bei einigen Nix-Paketen sind Funktionen unter macOS deaktiviert, offenbar weil die jeweiligen Paket-Maintainer keinen Mac zum Testen haben
  Auch die User Experience ist besser
  Natürlich vermisse ich die Reproduzierbarkeit von Nix-Umgebungen und die Möglichkeit, leicht ein flake mit bestimmten Paketen zu bauen, aber insgesamt hat Brew mich zurückgeholt. Trotzdem mag ich Nix weiterhin und wir nutzen Nix auch in der Firma

  • Ich nutze nix-darwin und verwalte darüber auch Homebrew-Pakete. Das ist vielleicht einen Blick wert
    Mich würde interessieren, wofür ihr Nix in der Firma einsetzt. Es gibt ein paar Bereiche, in denen Nix passend wirkt, aber es ist schwer, das genau festzumachen
  • Ich hatte Interesse an Nix, weil es so wirkte, als könnte man damit macOS-Funktionen, Einstellungen und Konfiguration automatisieren
    In der Praxis lief es aber meist darauf hinaus, defaults oder irgendwelche Zwischentools auszuführen
    Am Ende bin ich bei Brew geblieben und habe eine idempotente setupmac()-Funktion in mein bash_profile geschrieben. Ich nutze Bash 5, und ChatGPT hat mir geholfen, weil es sich gut mit nützlichen defaults-Befehlen auskennt
    Zusammen mit dem Brewfile, das ich in meinen dotfiles pflege, hat das fast alle Probleme beim Einrichten neuer Accounts oder Macs gelöst, sodass ich solche schwergewichtigen Tools nicht brauche

• Homebrew ist ein gemeinnütziges Projekt, das nicht von Angestellten, sondern vollständig von Freiwilligen betrieben wird
  Um Continuous Integration sowie die für künftige Verbesserungen nötigen Software-, Hardware- und Hosting-Kosten zu decken, braucht es Finanzierung
  Da alle Spenden laut eigener Aussage dafür verwendet werden, Homebrew für die Nutzer besser zu machen, lohnt es sich vielleicht, regelmäßige Unterstützung über GitHub Sponsors, OpenCollective oder Patreon in Betracht zu ziehen
  Ich habe schon viel an Open-Source-Projekte gespendet, von denen ich profitiere, aber über Homebrew habe ich nie wirklich nachgedacht, also sollte ich das wohl jetzt unterstützen

  • Es überrascht mich, dass Apple oder zumindest größere, Mac-zentrierte Entwicklungsfirmen Homebrew nicht sponsern

• Ich frage mich, ob man in Homebrew nicht eine Art Cooldown-Mechanismus einbauen könnte
  Die einzigen Parteien, denen ich vertrauen möchte, neuen Code schnell auf meine Maschine auszurollen, sind Apple und Browser. Browser, weil sie mehr hochgradig unvertrauenswürdige Eingaben verarbeiten als alles andere
  Bei allem anderen — vscode und Erweiterungen, npm, homebrew, Apps mit automatischen Updates — warte ich lieber ein paar Tage
  Bei einigen außergewöhnlichen 0-day-Fällen müsste man den Cooldown vielleicht umgehen können, aber schon jetzt bleibt man für 0-days verwundbar, bis der Nutzer brew upgrade ausführt

  • Unter https://docs.brew.sh/Supply-Chain-Security wird erklärt, wie man dort mit Cooldowns umgeht und warum das Risikoprofil ganz anders ist als bei NPM und Ähnlichem
    Außerdem gilt für Einträge, die aus NPM/PyPI/RubyGems übernommen und paketiert werden und bei denen solche Angriffe ein Thema sind, bereits ein Cooldown sowohl beim Paketieren als auch beim Erstellen eines PRs für ein neues Versions-Update
  • Gemeint ist hier eine Funktion wie --minimum-release-age oder minimumReleaseAge, um die Anfälligkeit für Supply-Chain-Angriffe zu verringern
    Solche Angriffe werden oft innerhalb weniger Tage nach einer Kompromittierung entdeckt
    Ein Beispiel aus Bun: https://bun.com/docs/pm/cli/install#minimum-release-age
  • Meistens wird das über Release-Kanäle gelöst. Zum Beispiel mit brew set-channel stable/edge
    Diese Woche hatte ich nach der Ankündigung von Elixir 1.20 nur ein paar Minuten Zeit, es auszuprobieren, und es hat mich genervt, dass Brew hinterherhing
    erl und elixir kann man auch auf andere Weise installieren, und persönlich bevorzuge ich ohnehin die jeweils eigene Toolchain, aber in dem Moment war mir das den Aufwand nicht wert
    Bei Brew gab oder gibt es für manche Rezepte Source-Optionen, und mit etwas gutem Willen ist auch das im Grunde eine Lösung
  • Es ist alles Rolling Release, aber bei Homebrew müssen die Homebrew-Maintainer die Version anheben, nicht die Software-Autoren
    Ausnahmen sind Fälle, in denen die Autoren selbst einen PR für Homebrew core einreichen oder einen eigenen Tap veröffentlichen. Ich frage mich, wie Arch das an dieser Stelle handhabt
  • Das ist in diesem Release enthalten. Siehe den Abschnitt „Cooldowns, livecheck and bumping“

• Applaus für alle, die Homebrew möglich machen. Man sollte vielleicht erwägen, das Projekt zu unterstützen: https://opencollective.com/homebrew

• Die Einstellung der Intel-Unterstützung wirkt aggressiv
  Fast alle Hobby-Nutzer, die Macs als Server verwenden, nutzen ältere Maschinen, und die meisten davon sind Intel-Geräte. Sie verlieren die Unterstützung fast ein Jahr früher als bei Apple
  Mir ist klar, dass Intel-Support mühsam ist und eine Frage der Wahl, aber ich finde, Homebrew sollte einen Weg suchen, Intel so lange wie möglich zu unterstützen

  • Tatsächlich scheint die überwältigende Mehrheit der Apple-Enthusiasten inzwischen vollständig auf Apple Silicon umgestiegen zu sein
    Ich würde vermuten, dass die Zahl der Leute, die alte Macs als Server betreiben, nicht über das Niveau eines Rundungsfehlers hinausgeht
  • Wenn Apple auch nur einen Teil seiner Ressourcen dafür eingesetzt hätte, etwas wie Homebrew zu pflegen oder die Menschen dafür zu bezahlen, hätte die Lage vielleicht anders ausgesehen
  • Zu diesem Zeitpunkt dürfte es bei den betroffenen Intel-Macs eher um einen Mac mini von 2018 gehen, der ohnehin nur bis Sequoia läuft und genau dann aus dem Support fällt, wenn Homebrew die Intel-Unterstützung einstellt
    Wenn Intel-Support nötig ist, läuft MacPorts sogar noch auf Leopard
  • Die Unterstützung für das Flag --no-quarantine wurde ebenfalls entfernt
    Inzwischen nutze ich Homebrew nur noch für ein paar casks und versuche es sonst zu vermeiden. Für CLI-Tools nutze ich Nix, Home-Manager und Nix-Darwin
  • Zum Glück eignen sich solche Maschinen immer noch perfekt für Linux-Distributionen

• Nachdem ich zu oft von erzwungenen Upgrades betroffen war, habe ich persönlich aufgehört, Homebrew zu verwenden.
  Stattdessen nutze ich jetzt eine Kombination aus Mise und MacPorts, um unerwartete Brüche und erzwungene Veralterung zu vermeiden.
  Außerdem kann man mit Mise auf beliebige neue Versionen aktualisieren, während man bei Homebrew darauf warten muss, dass ein Tap das Upgrade bereitstellt. Das llama.cpp-Tap überspringt dabei teils sogar 10 Releases.

  • Es freut mich wirklich, dass du einen Workflow gefunden hast, der für dich passt.
    Es wurde viel Arbeit investiert, damit Upgrades nur dann erfolgen, wenn sie wirklich nötig sind, und damit Nutzer vor dem Upgrade sehen, was passiert — das ist auch in diesem Release enthalten.
  • Ich wollte gerade fragen, ob noch jemand ähnliche Erfahrungen gemacht hat.
    Für die Installation von Entwickler-Tools nutze ich seit Jahren MacPorts; es ist deutlich konsistenter und überrascht mich nicht mit zufällig auftauchenden neuen Major-Versionen von Python.
    Homebrew verwende ich nur noch, um Anwendungen wie Firefox, Slack und Spotify zu installieren, die es in MacPorts nicht gibt.
    Natürlich versuche ich seit Jahren, bei Python auf uv und bei nodejs auf pnpm umzusteigen, daher ist das für mich inzwischen vielleicht kein großes Problem mehr.
  • Wegen Homebrews aggressivem Zeitplan zum Einstellen von Support-Stufen bin ich zu MacPorts gewechselt: https://docs.brew.sh/Support-Tiers
    Mein täglich genutzter iMac ist jetzt im Tier-3-„Pech gehabt“-Bucket gelandet.
    Ich mochte Homebrew in der kurzen Zeit, in der ich es nutzen konnte, wirklich sehr, aber ich habe nicht vor, mich auf das Hamsterrad ständiger Hardware-Upgrades zu begeben, nur um es weiter benutzen zu können.
  • Ich bin gerade dabei, das meiste auf Mise umzustellen; für den Rest sollte ich mir wohl MacPorts ansehen.
  • Nix ist ebenfalls einen Blick wert. Auch wenn das Darwin-Packaging etwas instabil ist, sind plattformübergreifende Development-Shells wirklich großartig, wenn man häufig zwischen Mac und Linux wechselt.