- Refuse to create bottles which have non-relocatable references to
`HOMEBREW_LIBRARY`. This allows us to make all bottles ignore where
`HOMEBREW_REPOSITORY` is (even those that aren't `cellar :any`).
I cannot see any circumstances in which any bottle should link to
anything within `HOMEBREW_REPOSITORY`.
- Remove audit that becomes unnecessary given the above change.
- Relocate references to `@HOMEBREW_LIBRARY@` but don't actually write
any references yet. This will allow us to move to using
`@HOMEBREW_LIBRARY` and remove all relocation of `HOMEBREW_REPOSITORY`
in a future release (2.7.1, most likely).
- Extract the json reading from the json merging: it makes the code hard to understand.
This helps for the separation of concerns: the jsons are read in one method;
and merged in a second one
- Added a first test to check the merge function
No change in behaviour was done, this change is just there to increase code coverage
and to prepare for #9315
The first attempt to build and pull a formula (hello) for linux in homebrew-core
resulted in a wrong cellar line being added to the formula's bottle block.
How to test/debug this, using the 4 bottles that where built for hello:
brew bottle --merge --debug hello--2.10_1.mojave.bottle.json hello--2.10_1.x86_64_linux.bottle.json hello--2.10_1.big_sur.bottle.json hello--2.10_1.catalina.bottle.json
This command would add create the following bottle block:
bottle do
cellar "/home/linuxbrew/.linuxbrew/Cellar"
sha256 "a0af7dcbb5c83f6f3f7ecd507c2d352c1a018f894d51ad241ce8492fa598010f" => :big_sur
sha256 "5334dd344986e46b2aa4f0471cac7b0914bd7de7cb890a34415771788d03f2ac" => :catalina
sha256 "22948764d8f8d7be4870ff92dae64d986eb63a9150b219c20fff87d1a6aa93d6" => :mojave
sha256 "702dc7f78444d2f4f1c19324be654bcbb8b99dd0e9ce26c3e2fbc3b6464a189f" => :x86_64_linux
end
After the change in this PR, the result is the following:
bottle do
sha256 "a0af7dcbb5c83f6f3f7ecd507c2d352c1a018f894d51ad241ce8492fa598010f" => :big_sur
sha256 "5334dd344986e46b2aa4f0471cac7b0914bd7de7cb890a34415771788d03f2ac" => :catalina
sha256 "22948764d8f8d7be4870ff92dae64d986eb63a9150b219c20fff87d1a6aa93d6" => :mojave
sha256 "702dc7f78444d2f4f1c19324be654bcbb8b99dd0e9ce26c3e2fbc3b6464a189f" => :x86_64_linux
end
The brew bottle --merge code will pick the most common cellar line between the 4 bottles, by order of priority:
- non-relocatable (fixed cellar path)
- cellar :any
- cellar :any_skip_relocation
In the case of the hello bottle, the 3 mac bottles are "cellar :any_skip_relocation", and the linux bottle
is non-relocatable. So the linux bottle wins and the code correctly determines that the 4 bottles should
be non-relocatable.
In that case, the /home/linuxbrew/.linuxbrew/Cellar path is defined as cellar, and by convention
we do not write that out to the formula file, hence the cellar path check that needs to be modified
in this PR.
This PR also fixes the same situation for mac ARM cellar paths
- Output `brew doctor` and `brew install` messages noting this configuration is (currently) unsupported and encourage use of Rosetta instead
- Output Rosetta 2 usage in `brew config` on ARM (whether in Rosetta 2 or not)
- Check the architecture of (newly installed) dependencies and ensure they are using the correct architecture.
- Don't allow installing macOS Intel Homebrew in macOS ARM Homebrew default prefix (and vice versa
- Actually write out the architecture of dependencies to the tab rather than generating and throwing them away
- Set and document the expected default prefix for macOS Intel Homebrew, macOS ARM Homebrew (`/opt/homebrew`) and Homebrew on Linux
While we're here:
- Don't say Big Sur is a prerelease version but still make it clear we
don't support it (yet).
- Don't reference non-existent IRC channel
We're using essentially the same logic to setup Git for committing in
multiple places but the way we're doing so is inconsistent. Moved to
using two shared utility methods and use them consistently.
- Sorbet gives preference to class methods over methods defined in
included modules, hence Sorbet was unavailable to resolve the
definition of the gsub! method.
- The gsub! method in StringInreplaceExtension conflicts with the definition in String.
- This PR refactors the call to the gsub! method so that a custom object
is exposed instead of a string.
Elide root_url only if it is precisely equal to the default root_url.
Eliding root_url when a prefix matches the default also elides
a custom root_url such as https://linuxbrew.bintray.com/bottles-bio.
