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
- don't include GitHub Actions credentials
- generate and include RTF version of Homebrew BSD license
- create nicer installer with `productbuild`
- customise welcome/conclusion messages
- add Homebrew logo as a background image
- remove unnecessary `preinstall` script
- cleanup `postinstall` script to pass `brew doctor`
- use `Distribution.xml` for a nicer installer
- require CLT or Xcode rather than using our hacks to try and install
CLT during installation