- remove all places we check the flag so it's a no-op now
- flip the messaging to refer to `HOMEBREW_NO_INSTALL_FROM_API` where
relevant
- adjust the documentation
When either being in a non-default prefix or being on an unsupported
macOS version we expect most things to be built from source. In that
environment, do not allow HOMEBREW_INSTALL_FROM_API to be set.
Fixes#14475
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>
- Output `brew doctor` and `brew install` messages noting this configuration is (currently) unsupported and encourage use of Rosetta instead
- Output Rosetta 2 usage in `brew config` on ARM (whether in Rosetta 2 or not)
- Check the architecture of (newly installed) dependencies and ensure they are using the correct architecture.
- Don't allow installing macOS Intel Homebrew in macOS ARM Homebrew default prefix (and vice versa
- Actually write out the architecture of dependencies to the tab rather than generating and throwing them away
- Set and document the expected default prefix for macOS Intel Homebrew, macOS ARM Homebrew (`/opt/homebrew`) and Homebrew on Linux
While we're here:
- Don't say Big Sur is a prerelease version but still make it clear we
don't support it (yet).
- Don't reference non-existent IRC channel
This allows the bootstrap of `curl` and `git` on versions of Mac OS X
that cannot reliably download from HTTPS servers any longer. Once these
are both installed users are able to update Homebrew and download files
securely.
Also, as we're doing this, don't point 10.5 users to Tigerbrew as they
are already given caveats for using Homebrew itself.
GitHub now nicely generates a documentation site for us at
http://brew.sh/brew based on our docs folder. Optimise the output of
this and the GitHub docs directory for readability and the various user
groupings.
