This allows us to remove all the manual timestamp fiddling and lets
`gnu-tar` handle it for us instead (as-per the most recent
recommendations on https://reproducible-builds.org/docs/archives/).
Some formulae (e.g. `luv`) have a `lib/lua/5.1` subdirectory inside
their keg. Before this change, the `5.1` subdirectory is symlinked into
`HOMEBREW_PREFIX`.
This can result in `luarocks` installing things into a formula's keg,
which we don't want.
Let's fix that by making sure that `brew link` creates these
subdirectories instead of symlinking them. We already do this for
subdirectories of `share/lua`:
8dd96ae8ba/Library/Homebrew/keg.rb (L430)
Previously, `brew upgrade gcc@10` could get overzealous and remove the
`LinkedKeg` record for `gcc@9`. This is bad because we then think
`gcc@9` is unlinked when it is not and it causes a tonne of conflicts
when trying to link `gcc@9` again.
Instead, fix up the alias and versioned alias cleanup to be more
precise and only delete the symlinks that point to the current `rack`,
`opt_record` or `linked_keg_record` and unify the logic so it's
performed consistently.
While we're here:
- don't `remove_old_aliases` every time we try to unlink a directory
but just perform it once per `unlink` operation
- remove the linked keg record on `uninstall`
This is weird. We're seeing some installs where formulae
have no opt prefix and no linked keg record, *but* still
ended up linked into the prefix. Upgrades will blow up in
this case because the old symlinks won't get deleted and
Homebrew will report a nonsensical error message about
not being able to link over another link from the same
formula!
Since the optpath is either missing or pointing to the
wrong destination at this point, the checks for conflict
linking above will have failed. We should instead be safe
to simply blow away these conflicting symlinks and replace
them with the new targets.
Fixes https://github.com/Homebrew/homebrew-core/issues/68866.
- manually `raise Errno::ENOENT` to ensure that a keg that doesn't exist
isn't flagged as a system dependency.
- remove the inconsistent and incorrect summary messaging.
The way we currently handle @-versioned formulae linking is pretty
labourius:
- it requires extensive use of `link_overwrite` to avoid the `link`
stage failing on certain install/upgrade scenarios
- we teach people to use `brew link --force` whenever they wish to
link a versioned formulae when it's pretty obvious what's expected
in that situation
Instead, let's:
- automatically unlink other versioned formulae when linking a
versioned formula (either through `brew link` or `install`/`upgrade`
/`reinstall`)
- notify the user what we've done (with the same messaging as if
they had run `brew link` manually)