Rather than automatically upgrading a formula from one tap to a formula
from another when specified as a dependency require a manual
intervention to be clear that's the user's intention.
Use the environment variables set by `brew test-bot`. Eventually we'll
disable Travis CI running CodeCov so move `TRAVIS` references to
`HOMEBREW_TRAVIS_CI` so it doesn't need whitelisted.
Also, fix `azure-pipelines.yml` so it's testing the correct version of
Homebrew/brew (the one checked out in the `pwd`).
Consolidate the handling of which directories need to exist and which
need to be writable. Additionally, add a fatal check for formula
installations to ensure that any directories that need to be writable
are so before attempting an installation.
Fixes#4626.
Replaces our serialization of child process
errors via Marshal with JSON, preventing
unintentional or malicious code execution outside
of the build sandbox.
Additionally, adds tests for the new behavior.
Use 124 max line length everywhere. Also, reduce tap max line length to
189 as Homebrew/homebrew-core has that as a maximum now. In future
Homebrew/homebrew-core will also be reduced to 124 maximum line length.
Instead of refusing to install software preemptively by assuming
multiple linkage to differing versions of the same library we now make
`brew linkage --test` verify that we don't have two versions of the
same library linked at the same time.
This will be considerably more permissive whilst checking the actual
problem that we're worried about.
Hopefully put this to bed for once and for all. Add a new method
`runtime_formulae_dependencies` which returns the `runtime_dependencies`
which have only the `Formula` objects that exist. I've checked all the
`runtime_dependencies` callers and updated them accordingly.
Also, fix a few cases where runtime dependencies were being read from
the tab when this wasn't desirable.
When a build dependency has a requirement it should be ignored when
checking for valid requirements. This requires calculating the
dependencies for a formula again and checking them when calculating
which requirements should be pruned.
Postinstall should be executed with the spec of the target formula not
the spec argument from ARGV, otherwise the prefix can be incorrect. In
other words, if the stable version of a dependency gets installed,
postinstall for the dependency should use the prefix of the dependency's
stable version, not the prefix of its devel or head version.
Fixes#2941.
Rather than using the name of the keg for the key use the full path.
This provides several advantages:
- there's no need to invalidate the cache on a `brew upgrade` or
`brew switch`
- it's easier to figure out what cache entries can be removed and this
can be done whenever a keg is removed by `brew uninstall` or
`brew cleanup`.
Also, ensure that an `install` (or `reinstall`, `upgrade`) always
results in the cache being rebuilt for that keg (in case different
options were used).
Instead of adding a custom method to `Tab` use `Tab.runtime_deps_hash`
within `FormulaInstaller` to ensure the `runtime_dependencies` are in
the right format.
This ensures the we’re calculating we’ve run `fix_dynamic_linkage` so
that their results are consistent with what we’re actually pouring.
Combined with the linkage cache (which will be enabled by default in
future) this has very little performance overhead for consistently
Correct tab results.
As a result, don’t bother looking at opportunistically linked
dependencies when creating a tab by default but only do so after
installation has completed.
Finally, only output the caveats and summary after all these
operations have completed.
1. Running `brew linkage some_package` does not set the cache.
2. Running `brew linkage --cached some_package` when `DatabaseCache.empty?` returns `true` should build the cache.
3. Running `brew linkage --cached some_package` when `DatabaseCache.empty?` returns `false` should use the cache.
Allow at `install` (or `install --only-dependencies`) time to specify
that test dependencies should be installed. This will allow simplifying
code in `brew test-bot`.
This could also be made an environment variable if desired by
maintainers.
It only makes sense to tell a user to try installing from a bottle if
there are bottles available for them to install for all the formulae
they specified.
This has been a nightmare in terms of the complexity to our dependency
system and the whack-a-mole required on bugs. If a Requirement resolves
to a Formula it should just use `depends_on "formula"` instead. This
matches the effective behaviour all users of bottles (the vast majority
of users and installs) and what we're doing in Homebrew/homebrew-core.
It's not possible to determine the difference between a non-keg-only
keg that failed to link and one that wasn't linked by us intentionally.
To avoid additional complexity of storing this logic in another place
let's back out this relatively new functionality; sticky keg-only links
is a better and more desirable behaviour anyway.
