- flip the messaging to refer to `HOMEBREW_NO_INSTALL_FROM_API` where relevant
- remove some duplicate checks
- better scope checks to just core tap formulae
Given a `pkg_a` that depends on `pkg_b`, it is redundant to list
`pkg_b` as a dependency when running the following commands:
- `brew install pkg_b pkg_a`
- `brew upgrade` (when both `pkg_a` and `pkg_b` are outdated)
We're still getting a non-trivial number of issues from configurations
we don't support and don't plan to.
Let people know that we know their experience will not be good and what
to expect if they file issues.
Co-authored-by: Eric Knibbe <enk3@outlook.com>
Right now this is done through the gcc@5 formula.
See 9692318ca6/Formula/gcc%405.rb (L33)
This is fragile because when we will migrate to gcc@11
we have to think about migrating the installation from one gcc formula to another..
Also, not having the right glibc version results in a non-functional brew
installation on an older Linux: the glibc installation needs
to be done by brew, and not by a workaround in a specific formula
Co-Authored-By: Mike McQuaid <mike@mikemcquaid.com>
Co-Authored-By: Bo Anderson <mail@boanderson.me>
Co-Authored-By: Shaun Jackman <sjackman@gmail.com>
- For a formula with an architecture requirement and a user requesting
`--only-dependencices` to be installed, this now proceeds to install the
formula dependencies regardless of the requested formula architecture because
the formula itself will never be installed.
- The way dependencies and requirements are computed, the `depends_on :arch` is
still a dependency, so it's in the list of formula dependencies to check and
potentially install. Hence, we have to remove from the list the dependent
from `recursive_requirements` with the same name as the formula so that there
are no confusing unsatisfied requirements for the named formula when we don't
need it to be installed.
- I thought about why this might be, maybe it's because we can't guarantee that
formula dependencies work on different architectures. But in that case they'd
have their own architecture requirements, so we'd see the failure for them.
So I don't know of any more reasons.
Before:
```shell
$ brew install --only-dependencies julia
julia: The x86_64 architecture is required for this software.
Error: julia: An unsatisfied requirement failed this build.
```
After:
```shell
❯ brew install --only-dependencies julia
==> Downloading [...]
==> Installing dependencies for julia: libnghttp2, mpfr and suite-sparse
```
ruby-macho chokes on changing duplicate RPATHs, so we need to strip the
duplicates before trying to relocate them.
This continues #11405. We need this to unblock
Homebrew/homebrew-core#91224.
While we're here, let's get rid of `HOMEBREW_RELOCATE_RPATHS`. We've
been using it for nearly a year with essentially no problems (barring
`pdnsrec`), so I think it is safe to do unconditionally.
Allows you to avoid the `Keg::ConflictError` recommending that you invoke `brew link --overwrite` in scenarios when you know that that's how you'd proceed anyway.
There's a few bits of functionality that Homebrew has changed over the
years, makes sense as a sensible default but some people find really
annoying:
- automatically running `brew update`
- automatically running `brew cleanup`
- automatically upgrading outdated dependents
- automatically reinstalling broken dependents
For each of these: let's improve the documentation of the commands
whose behaviour is changed and the environment variables themselves.
