Homebrew: Detailfragen für Best Practise beim Updaten von Casks

[spinmaster]

Hallo Leute,

gibt es hier User die Homebrew/Brew schon länger für die Installation der ganzen Mac Apps und Programme nutzen? Ich nutze Brew jetzt schon eine ganze Weile und seit meinem frischen Monterey Reinstall nun auch komplett für die ganzen Standardapps die man sich normalerweise als erstes installiert (Firefox, LibreOffice, usw.). Vorher hatte ich mir eher ausschließlich Spezialsachen mit diversen Dependencies installiert (Skripte oder Spezialtools).

Mal an die Brew-Gurus unter Euch: zwei Dinge speziell bei den Updates der Casks würden mich mal interessieren:

1) Wie gehe ich am besten vor, wenn mein per Brew installiertes Programm (mein installierter Cask) ein Auto-Update innerhalb des Programms vorschlägt? Wenn ich das richtig gelesen habe, sollte man generell In-App Updates vermeiden um Konflikte mit dem Brew-Versionsmanagement zu vermeiden (weil Brew das In-App Update nicht mitbekommt und im Zweifel später eine alte Version beim nächsten brew update rüberbügelt).

Ich stelle also als erstes Auto-Updates nach der Brew Installation des Casks aus - weil ich ja ausschließlich per "brew update" meine Versionen hochziehen will. Ist das so "best practise"? Oder sollte man hier noch etwas beachten?

Das bringt mich gleich zu 2):

Was aber, wenn es sich um ein eher unpopulären Cask handelt, der länger nicht auf GitHub (wo ja die Cask Codes zum Update gehostet werden) von der Community nachgezogen wird?

Beispiel: Ich nutze den TinyMediaManager, eine Java App zum Pflegen von Mediensammlungen wie Filmen (Artwork, Metadaten, usw.).

Aktuelle Version seit neustem: 4.2.5 (https://www.tinymediamanager.org/blog/version-4-2-5/)
Auf GitHub ist aber noch der Cask Code für 4.2.4 (https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/tinymediamanager.rb) und die 4.2.4 ist bei mir installiert.

Was mache ich in dem Fall? Die Füße stillhalten bis sich jemand erbarmt auf GitHub den Code für 4.2.5 nachzuziehen, so dass alle User per brew auf 4.2.5 updaten können und solange die alte 4.2.4 nutzen? Was, wenn das in den nächsten Wochen nicht geschieht? Ist ja freiwillig, basiert alles auf Mitarbeit der Brew Community.

Oder muss ich - wenn ich das richtig verstanden habe - tatsächlich dann meinen eigenen Fork des Cask Codes lokal anpassen (updaten) und dann online einchecken, so dass ein Pull Request für das Homebrew Team getriggert wird und dann im Repo für alle zur Verfügung steht? (Würde ich mich noch nicht trauen, weil ich selbst noch keine GitHub Erfahrung habe).

Freue mich über ein Feedback!

 

[Wuchtbrumme]

Ist richtig wie Du sagst. Paketmanager brew nur für die Casks benutzen, die es liefert und nicht drumrum reinbasteln.

 

[spinmaster]

Danke @Wuchtbrumme ! Es gibt ja noch den Fall, dass sich einige Casks auch nicht über "brew upgrade" neu updaten - siehe hierzu auch letzter Artikel im Homebrew FAQ https://docs.brew.sh/FAQ

Mir war das so neu, dass diese Casks - nehmen wir mal Firefox als Beispiel - das "auto_updates" Flag haben, also man per "brew update" zwar eine Info über eine neue Version bekommt, diese per "brew upgrade" aber nicht installiert wird.

Beim Beispiel Firefox mal geblieben: wie gehst Du oder andere denn für solche Casks genau vor? Was ist sinnvoll?

1. Apps die sich auto-updaten wie Firefox, das Auto-Update erlauben - also keine weiteren Cask-Updates über Brew nach dem initialen Cask-Install mehr installieren?
2. Im Firefox das Auto-Update ausstellen, die Info auf ein neues Cask-Update in Brew für Firefox zur Kenntnis nehmen und per "brew upgrade firefox" händisch dann nachziehen (zu forcieren)?

Ich habs jetzt tatsächlich wie 2) gemacht, um die Updates konsistent in Brew zu managen - im Zweifel halt auch händisch wenn per "brew outdated --greedy" Casks auftauchen, die sich eben nicht automatisch per "brew upgrade" aktualisieren und für die neue Versionen verfügbar sind.

Update: Hab erst jetzt gesehen, dass es auch per "brew upgrade --cask --greedy" möglich ist diese Art von Apps für 2) in einem Rutsch zu aktualisieren.

Feedback gerne.

 

[Wuchtbrumme]

Dazu kann ich nichts sagen, denn dieses Problem hatte ich noch nie. Auch verwende ich den Firefox nicht als brew cask (wusste nicht einmal, dass es den gibt). Wäre auch nie auf die Idee gekommen es zu nutzen, wenn... (gerade wegen des Autoupdates).

Aber es sind Probleme, wie es sie eigentlich alle Paketverwaltungen in unixoiden OS haben, solange nicht alle Abhängigkeiten innerhalb einer App für sich gelöst sind. Ich sag nur openssl.

Ansonsten sollte man mit einem nicht überbordenden Set an üblichen casks (ffmpeg, ...) eigentlich nicht auf die angefragten Probleme stoßen.

 

[spinmaster]

Es gibt neben Firefox tatsächlich alle möglichen populären Standardtools (welche frei verfügbar sind) als Cask per Homebrew. Und ja Du hast recht, die große Stärke spielt Homebrew aus bei Paketen mit sehr vielen Abhängigkeiten wie FFmpeg aus Deinem Beispiel. Da hast Du die Autoupdate Probleme natürlich nicht, weil diese Arten von Bibliotheken ja mehr oder weniger "statisch" in Deinem System liegen. Anders bei Desktop Tools wie ein Firefox der per Auto-Update proaktiv nach draussen funkt.

Ich denke ein Usecase solche Arten von Casks zu installieren ist eben auch, wenn man vielleicht initiell einen Mac aufsetzt und 50 Casks zum Installieren hat - und nicht 50 mal auf irgendwelchen Seiten was runterladen will und sich durch die Installationsroutine klicken muss. Ich kann ja auch alle meine Casks in einem Brewfile definieren und dann alles zum Installieren durchrutschen lassen.

Egal: ich habs jetzt trotzdem so gemacht, dass ich in den Auto-Update Programmen alles zum automatischen Updaten ausgestellt habe und wirklich rein per Brew zum Updaten nutze (also auch bspw. inkl. Firefox). Wenn ich per "brew update" dann die Info kriege, dass ein Auto-Update Cask dabei ist, forciere ich das Update eben per "--greedy" Flag.

Mal schauen wie das so weiter klappt. Mich würde trotzdem interessieren wie es andere diesbzeüglich handhaben. Gerne daher weiter Feedback von anderen!