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>
This avoids can avoid UID/EUID related issues with Ruby scripts passed
over `stdin` clashing with Ruby security features.
It's also just a bit nicer to have Ruby scripts in files instead.
While we're here:
- refactor some shared logic into a new `setup-gem-home-bundle-gemfile`
function in `ruby.sh`
- do some general cleanup of `lock.sh`
- prioritise `flock` over `python` in `lock.sh`
If you're e.g. running Homebrew over `sudo`: shelling out to `whoami`
is less effective than just telling people which user you're running
as when we run the check.
Fixes (on centos6):
which: no flock in (/home/linuxbrew/.linuxbrew/bin:/home/linuxbrew/.linuxbrew/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)
Ruby first gained flock in 1.8.7, which is a problem since we're using
this lock utility in `vendor-install` in order to install a newer Ruby.
Fortunately, Python 2.3(!) has flock support.
Since #292, HOMEBREW_CACHE was moved to a per-user directory. This makes
it unsuitable to store global lock files on multiple users environment.
Therefore, introducing a global lock directory `/Library/Lock.d` to
store lock files from formula lockers as well as `brew update`.
