My experience recently playing around with our locking behaviour is
that, while mostly seamless and not seen by users, it's leaks
implementation details a bit too heavily.
As a result, the following improvements are in this commit:
- Ensure that, whenever possible, we tell the user the actual command
that is holding a given lock instead of the lock name (an internal
implementation detail)
- Make the locking error output a little more consistent and user
friendly
- Add a `DownloadLock` class to simplify locking downloads
- Add a `HOMEBREW_LOCK_CONTEXT` variable to allow adding additional
context for logging error messages
- Lock paths and leave deciding how this translates to lock names up
to the locking code itself
- Lock the Cellar/Caskroom paths explicitly rather than implicitly
Co-authored-by: Carlo Cabrera <30379873+carlocab@users.noreply.github.com>
- Use the `HOMEBREW_PORTABLE_RUBY_VERSION` environment variable to
determine the version of the Portable Ruby to use in
`vendor-install.sh` and `ruby.sh`.
- Replace the `docs/.ruby-version` file with a symlink to
`Library/Homebrew/.ruby-version`.
- Fix an incorrect `HOMEBREW_LIBRARY` comment.
- Use a simpler `HOMEBREW_USING_PORTABLE_RUBY` definition.
If `shasum` is broken and doesn't produce a valid checksum: we were
just doing the checksum comparison with an empty checksum.
Instead, let's treat an empty checksum as a failure condition, rather
than just the executable bit being present for the relevant binary, and
iterate through the available tools to try and get a non-empty checksum.
If they all produce an empty checksum: provide a different error to make
it a bit more obvious what's happening here.
This fits the use-case I've heard multiple times where people want to
rely exclusively on their artifact provider.
Co-authored-by: Carlo Cabrera <30379873+carlocab@users.noreply.github.com>
This can be useful when testing fetch on a different processor than the
one the user is running on.
While we're here, refactor code run on `source` to need a function call
instead.
Whenever the `sysctl` call does not match `"Apple"*`, we can be sure
that `HOMEBREW_PROCESSOR` is `Intel`, so there's no need for this
additional check.
The previous commit only prevented the installation of an Intel Portable
Ruby into `/opt/homebrew` prefix. Let's actually install an ARM64
Portable Ruby there too.
Since `HOMEBREW_PROCESSOR` is populated using `uname -m`, this will
register as `Intel` even when a native ARM install is running under
Rosetta.
Let's work around this by checking `sysctl -n machdep.cpu.brand_string`.
On my Intel machine:
❯ sysctl -n machdep.cpu.brand_string
Intel(R) Core(TM) i3-1000NG4 CPU @ 1.10GHz
On Apple Silicon:
brew@HMBRW-A-001-M1-001 ~ % sysctl -n machdep.cpu.brand_string
Apple M1
The case of a Rosetta installation of Homebrew is already handled below
the proposed change.
FixesHomebrew/discussions#2434.
Remove all code related to Bintray. It no longer works so there's no
point keeping it around.
Some of this could arguably be deprecated/disabled first/instead but:
I'm not sure I see the sense in keeping stuff around that's known to be
broken.
A new version of `shellcheck` (I think?) brought us so new warnings and
errors.
To fix:
- pass `--source-path` so we don't need to stop `shellcheck` trying to
read sourced files every time
- disable some more warnings/errors we don't care about fixing
