- Use raw.githubusercontent.com to download cask source rather than
formulae.brew.sh. This allows us to remove these files
- output the tap's current `HEAD` for both formulae and cask JSON
- use this `HEAD` for the cask-source API to get the exact file on
raw.githubusercontent.com rather than just whatever is newest (which
is what the previous API did)
- set the `Tap` correctly when creating a `Cask` from the API
- if the `formula.json` file exists: print its modified time include
`brew config`
- memoize `tap.git_head` as we'll be calling it a lot in the same
process with the same value
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>
Setting `target` to a path outside `HOMEBREW_PREFIX` is not portable,
and will be invalid for some Homebrew installations.
If we want to add an `rpath` outside of `HOMEBREW_PREFIX`, we should
just use the absolute path instead.
See discussion at Homebrew/homebrew-core#110520.
Now the build dependencies of formula that were installed from
source will not be removed by `brew autoremove`. This is especially
helpful for those who've installed brew in an alternative prefix.
We added the `--all` flag (now renamed to `--eval-all`) for various
commands for this behaviour so let's start deprecating this.
Also, introduce a `HOMEBREW_EVAL_ALL` environment variable to use the
existing, less secure, behaviour by default and avoid passing
`--eval-all` everywhere.
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>
There are about 10 formulae which need a bit more flexibility from
`#rpath`. Most of them use `Pathname#relative_path_from`, so we can
replace those instances with a call to `#rpath` instead once `#rpath`
knows how to handle this.
