- warn if running `brew postinstall` explicitly and there's no
`post_install` defined in the formula
- add a `post_install` alias for `brew postinstall` to make life
easier for those jumping between `postinstall` and `post_install` in
e.g. Homebrew development
- refactor `post_install` formula path logic into a new method for
improved readability
- handle the JSON API `post_install` formula path case
- This should help avoid this regressing
- Remove existing Homebrew installation(s)
- Install it twice to ensure that installing over the top of an existing
installation works as expected
- Remove existing API cache to ensure we have the freshest files from
the API in our package
When we're automatically setting `HOMEBREW_NO_INSTALL_FROM_API`
when on an old macOS version or with a non-default prefix (e.g. cases
where you're going to be mostly building from source).
My initial plan was to set
`HOMEBREW_AUTOMATICALLY_SET_NO_INSTALL_FROM_API` in these cases but
it's used differently enough it made sense to add another internal
variable instead: `HOMEBREW_INSTALL_FROM_API_UNSUPPORTED`.
At the moment this is only used to avoid printing the "You have set
`HOMEBREW_NO_INSTALL_FROM_API`" message inside `brew update` but may
make sense to use in other places over time.
Ideally, we'll get rid of these automatic sets of
`HOMEBREW_NO_INSTALL_FROM_API` and perhaps even the variable entirely.
Having this would have been, or would be, useful on multiple occassions:
- Homebrew/homebrew-core#94724
- Homebrew/homebrew-core#136551
- #15372
I think it's time that we added this back.
We can add a small amount of logic to `#resolve_variable_name` that will
allow us to perform (limited) resolution of rpath references. This is
for informational purposes only: failing to resolve an `@rpath`
reference will not (and should not) result in `brew linkage` failures.
`dyld` will typically have more information than we do to resolve these
references, so not failing `brew linkage` when we fail to resolve an
`@rpath` reference is the right behaviour here.
As an example, before:
❯ brew linkage jpeg-turbo
System libraries:
/usr/lib/libSystem.B.dylib
@rpath-referenced libraries:
@rpath/libjpeg.8.dylib
@rpath/libturbojpeg.0.dylib
After:
❯ brew linkage jpeg-turbo
System libraries:
/usr/lib/libSystem.B.dylib
Homebrew libraries:
/usr/local/Cellar/jpeg-turbo/3.0.0/lib/libjpeg.8.dylib (jpeg-turbo)
/usr/local/Cellar/jpeg-turbo/3.0.0/lib/libturbojpeg.0.dylib (jpeg-turbo)
My understanding from conversations with Bo98 is that this should now
work fine on both older macOS versions and non-default prefixes.
Similarly, it's super confusing when this is set automatically and you
can't figure out why...
Continuing with the goals of making the installer:
- more useful
- entirely offline
Let's pre-download the API data from a `brew update` run and install it
into the logged-in user's home directory.
While we're here, in the `postinstall` script:
- use longer arguments for various commands
- fix an issue with symlinking on Intel if `/usr/local/bin` doesn't
already exist
- unset `bash -x` and use `-v` on more commands instead
