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>
A resource can do `using: :homebrew_curl`, but, without this change, the
audit will still use system `curl`. This fails quite predictably.
Needed for Homebrew/homebrew-core#88330.
If the download url is using brewed curl, use that too for the homepage check.
Ideally one would introduce the "using: :homebrew_curl" stanza for the homepage
line in the DSL, but it is easier to implicitely use the same logic
for homepages and url's and define the "using:" only once.
