Open muneebmahmed opened 1 week ago
I did some more investigation with brew deps --tree --include-build --include-test --include-requirements --include-optional libomp
to find that libomp
has :build
dependencies on cmake
and lit
, and lit
has a :test
dependency on (Homebrewed) llvm
. So, in the full dependency graph, llvm
is brought in as a test dependency of a formula that is a build dependency. With that in mind I tried adding
next if dep.test?
to line 382 here: https://github.com/Homebrew/brew/blob/3291ad4fc78f33f8e9bb7ce37745d2a0e697f5fb/Library/Homebrew/formula_installer.rb#L380-L382
and it worked! I'm happy to create a PR, but I don't believe this approach is ideal. We're still generating the full dependency graph and then pruning build + test deps. If, for example, there's a formula that's a required dep of a build dep, it will remain and halt the upgrade. In my opinion, it would be better to not even recurse on build dependencies in the first place when creating the graph.
Here are the dependency walking functions in question: https://github.com/Homebrew/brew/blob/3291ad4fc78f33f8e9bb7ce37745d2a0e697f5fb/Library/Homebrew/dependency.rb#L128-L179 It would be easy to add something like
elsif dep.build? || dep.test?
prune
after line 176, but this would probably impact other places where expand()
is called and test/build dependencies are expected to remain in the graph. Could this be refactored to conditionally prune build/test dependencies based on parameter flags? That change goes beyond my familiarity with the homebrew codebase however, so I'm not sure I can make that fix
I'm happy to create a PR, but I don't believe this approach is ideal.
Please do, that's much easier to discuss than the issue as-is. This document should help and we're happy to walk you through anything else.
Thanks!
brew doctor
outputVerification
brew doctor
output" above saysYour system is ready to brew.
and am still able to reproduce my issue.brew update
twice and am still able to reproduce my issue.brew install wget
. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.brew config
outputWhat were you trying to do (and why)?
After upgrading my Intel MacBook to Sequoia (from Monterey), I ran
brew update && brew outdated
, decided tobrew pin llvm
as it's 2GB and I didn't want to download all of it, then ranbrew upgrade --formula
. A number of formulae were unable to be upgraded due to a dependency on llvm; however, I confirmed withbrew uses llvm --installed --include-build --include-test
that no formula on my system depends on llvm, and it is in fact included in the output ofbrew leaves
What happened (include all command output)?
What did you expect to happen?
All the formulae should have upgraded and been poured from bottle as none of them depend on llvm. I looked through the four that didn't upgrade and:
fastfetch
has a build (not runtime!) dependency onimagemagick
; its formula doesn't mention llvmimagemagick
has runtime dependencies onlibraw
andlibomp
; its formula doesn't mention llvmlibraw
has a runtime dependency onlibomp
; its formula doesn't mention llvmlibomp
has no runtime dependencies, but it does haveuses_from_macos "llvm" => :build
in its formulaI suspect that
llvm
is not getting filtered out properly in the dependency graph somewhere. This problem is trivial to resolve with a simplebrew uninstall llvm
on my side, but I figured I ought to make a bug report regardless, as non-dependencies appearing in the dependency tree does appear to be a bug to me and it might affect other formulae.Step-by-step reproduction instructions (by running
brew
commands)I don't think homebrew has a way to downgrade formulae, but you could probably either download the older bottles and install them manually, or check out a version of homebrew-core from a month ago and set
HOMEBREW_NO_INSTALL_FROM_API=1
. For convenience, I've listed the formula versions currently on my system and corresponding bottle hashes:Run
Note that llvm had been built from source on my machine but all other formulae were poured from bottleI reinstalled llvm 19.1.0 using the Ventura bottle and confirmed that the issue is still present