- Fixes issue 14996.
- The API JSON is generated with a `/usr/local` Homebrew prefix, but
frequently now users have `/opt/homebrew` as their prefix. Since
formulae `keg_only` reasons are generated by the API, this can lead
to the confusing messaging that follows:
```
socket_vmnet is keg-only, which means it was not symlinked into /opt/homebrew,
because /usr/local/bin is often writable by a non-admin user.
```
- With this change, that formula as it is now will fail `brew audit`,
prompting to remove the prefix reference.
```
❯ HOMEBREW_NO_INSTALL_FROM_API=1 brew audit --strict socket_vmnet
socket_vmnet:
* `keg_only` reason should not include `HOMEBREW_PREFIX` as it provides confusing output.
Error: 1 problem in 1 formula detected
```
The `github_issue_comment` audit disallows references to closed or
merged PRs in other repositories. We should allow those, since it is a
common pattern to reference merged PRs in formulae when adding comments
that explain changes that need to be made in future versions (e.g.
`patch` blocks).
This audit is mistakenly passing for formulae where
`variations_dependencies` is an empty array. We can fix that by checking
for `nil` instead.
See Homebrew/homebrew-core#111280.
There is an audit for versioned formulae that makes sure
an unversioned formulae of the same name exists already.
This ignores that check when we exlicitly removed the
unversioned formula by checking if it was renamed.
Also, there is no need to check for formula.tap because
formula.core_formula? guarantees the presence of formula.tap.
The Git log is required only when `--strict` is not passed. This check
should still run with one of `--strict` or `--git`, but currently
passing `--strict` also requires `--git` in order to run this check.
This will still not be done during `tap_syntax` jobs after this change.
The GCC dependency check is adding a couple of minutes to our
`tap_syntax` jobs. Let's fix that by moving the check into a separate
method so we can exclude it from `tap_syntax`.
I am removing `glib-utils` in (1) Homebrew/homebrew-core#108307, and all
`glib-utils` dependencies in (2) Homebrew/homebrew-core#108497.
This audit prevents me from proceeding with (1) without rebuilding all
the formulae modified in (2). I don't think that is needed, so I'd like
to exempt `glib-utils` from the rename audit instead.
To give you a clearer idea of how I plan to do this, this is the order
of events:
1. Merge this change.
2. Merge Homebrew/homebrew-core#108307.
3. Merge Homebrew/homebrew-core#108497.
4. Revert this change.
This should allow us to get rid of `glib-utils` and its accompanying
hacks without having to rebuild dozens of formulae needlessly.
We have an audit that checks each formula's dependency tree for multiple
versions of the same software. We have an allowlist that allows us to
ignore this audit, but this allowlist requires each formula with a
conflict in its dependency tree to be listed there.
Here, I propose the reverse: if formula `foo` appears in the
`versioned_formula_dependent_conflicts_allowlist`, then all its
dependents will not fail the versioned dependencies conflict because of
a conflict with formula `foo`.
I'd like to do this in the case of `python`, where I think the versioned
dependencies conflict check hurts us more than helps us. Versioned
dependency conflicts are most problematic in the case of libraries with
the same install name but incompatible ABIs. This is almost never a
problem with Python: almost no formulae link with the Python framework
on macOS (in part due to one of our audits that disallows Python
framework linkage in Python modules). Moreover, the various Python
frameworks that we ship have the version in the install name.
The above _might_ be a problem on Linux, since we allow unrestricted
linkage with `libpython`. However, we don't even check versioned
conflicts on Linux, so we aren't as concerned about this in the first
place.
This is also a lot more convenient than adding the dependents of some
Python formula one by one as they acquire conflicts due to changes in
other formulae.
I've also amended `tap_auditor` to allow the use of formula aliases in
an allowlist, to allow us to add `python` to this allowlist instead of
each individual versioned Python formula.
See also discussion at Homebrew/homebrew-core#108307.
As we've seen, allowing Linux-only dependencies on GCC results in its
dependency tree growing out of control to the point of being extremely
painful to maintain.
Let's stop this situation from getting worse by:
- failing a `--strict` audit when there is a Linux-only GCC dependency.
This also prevents new formulae from having such a dependency.
- failing any audit whenever a formula that did not previously have a
Linux-only GCC dependency picks one up
If a future formula update causes a formula to fail to build on Linux
because it needs a newer GCC when it previously did not, then we should
not bottle it. We can bottle this hypothetical formula when our bottling
distribution includes a new enough version of GCC.
* Fix audit not being run at all due to always-false condition.
* Don't fail audit if versioned alias would clash with a versioned formula.
* Allow versioned aliases with the name of another alias.
Occasionally, we get PRs that attempt to add a dependency on a formula
in an external tap in homebrew/core (e.g. Homebrew/homebrew-core#94791).
We don't actually have an audit that disallows that. We should have one.
Logically new formulas should start at revision 0, but a
developer might use an existing formula as a template and
otherwise not realize they should remove this field.
Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>
