homebrew-core

y count, there are 81 such packages in homebrew-core, and the following is a complete list of all of those which appear in a `depends_on` declaration: antlr atkmm autoconf cairomm db elasticsearch erlang gcc ghc glibmm go gradle guile hdf5 headers helm isl libfuse llvm lua mbedtls mysql node numpy openexr openjdk openssl pangomm php proj pyqt pyside python qt ruby swig synth tbb vtk wxwidgets So when you look at a Postgres formula in the Homebrew repos and see that it declares an ‘unversioned’ dependency on openldap, for example[1], that does not mean that the formula author has declared ‘any version is fine’, i.e., it does not mean that the dependency is unversioned. It just means that the dependency's version constraints are totally unspecified except implicitly as ‘the only version of that package which is simultaneously present in the glorious monorepo of build recipes’. This is a feature it shares with some source-based package management systems, like Nix and Guix. Those package managers solve this problem by basically vendorizing everything, so installing a new package never upgrades anything else you have installed. Other source-based package management systems, like Portage and Pkgsrc, have extended their model to include some handling of version constraints, but they also sometimes declare dependencies without specifying a version. That seems dubious to me, since in reality there pretty much always are version constraints that ought to be specified there, but maybe those two projects are mature enough that they've hammered out the problematic cases by now. — https://github.com/Homebrew/homebrew-core/blob/master/Formul...

s! Homebrew doesn't even attempt to encode some very basic aspects of dependency, so now (a) you can't know what you're going to break if you do upgrade a common dependency and (b) you can't know when you can afford not to upgrade a dependency shared by a package you're about to install and the already-installed system. The choice you outline above is one that is not faced by most package managers, because they don't make this mistake. The naive wheel reinvention with Homebrew is so eternally disappointing, and it explains a lot of the pain users experience with it. > Homebrew upgrades dependencies and dependents of those dependencies (which, admittedly, can feel like unrelated) One relatively non-disruptive thing you might be able to do to make this behavior less surprising to users is (offer a way to?) print the dependency tree for package installations/upgrades that pull in upgrades of their ‘siblings’. You'd probably want to just do it in a textual way, but this project seems to model the kind of logic you'd want for printing dependency trees with Homebrew as it exists.[2] — 1: https://github.com/Homebrew/homebrew-core/blob/master/Formul... 2: https://github.com/martido/homebrew-graph/blob/master/cmd/br...

gets a quarantine flag triggering the Gatekeeper warnings. That Homebrew issue (from 2019 though...) seems to say that "bottles" installed via Homebrew (which is basically the same thing - a precompiled bin downloaded from internet) won't have the quarantine flag set and they just need to be ad-hoc code-signed.