[stonesweep]

To codify both replies to yours as an outsider who watches macOS coworkers struggle: brew is akin to running Arch, where the concept is latest-tagged-release of any given software.

The newest version of X introduces a feature which has a need of Y library (dependency) >= n+1, where n is your already installed version. It just so happens that Y is shared between 3 applications; so if you upgrade Y to satisfy X, you now have to recompile/upgrade (depending on details) A, B and C as well to use the newly updated version of Y.

Arch (and other rolling releases) do/does this every day, it's just that the work is offloaded to upstream packagers. Brew is more "AUR-like" where it's all down downstream on your own system, so you get to deal with the work and churn through the recompiles yourself.

[Hackbraten]

> Brew is more "AUR-like" where it's all down downstream on your own system, so you get to deal with the work and churn through the recompiles yourself.

I don’t see how Homebrew would be similar to AUR.

Unlike AUR contributors, Homebrew maintainers curate the packages, test them, monitor upstream projects for updates, build and upload binary packages and do their best to support users when anything breaks.

Anytime a Homebrew user installs a formula from homebrew-core and the system starts to (re-)compile, almost certainly something is wrong.

[stonesweep]

It depends on the formula, designs and maintainers of them - we run an internal tap and some items are casks, some are bottles and some are compile as you go. It just depends on what that widget is and does, and in some cases there are tools which are broken on latest-tagged releases and people have to pin older versions or using git HEAD for (some period of time) until the tagged released is fixed upstream. (we're looking at you, sshuttle-who-deprecated-remote-python2-in-v1.0-thru-1.0.4-and-broke-lots-of-workflows-with-jumphosts)