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>
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.
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.
`cleanup_path` already handles the dry-run logic, and also includes
those paths in the summary of space freed by `brew cleanup`.
Before this change:
❯ brew cleanup --dry-run
Would remove: /Users/carlocab/Library/Caches/Homebrew/bootsnap (2,401 files, 41.9MB)
After this change:
❯ brew cleanup --dry-run
Would remove: /Users/carlocab/Library/Caches/Homebrew/bootsnap (2,401 files, 41.9MB)
==> This operation would free approximately 41.9MB of disk space.
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.
