update-report: unlink rather than uninstall --force formula when migrating a formula to a cask
==============================================================================================
- [x] Have you followed the guidelines in our [Contributing](https://github.com/Homebrew/brew/blob/master/CONTRIBUTING.md) document?
- [x] Have you checked to ensure there aren't other open [Pull Requests](https://github.com/Homebrew/brew/pulls) for the same change?
- [ ] Have you added an explanation of what your changes do and why you'd like us to include them?
- [ ] Have you written new tests for your changes? [Here's an example](https://github.com/Homebrew/homebrew/pull/49031).
- [ ] Have you successfully run `brew tests` with your changes locally?
-----
Discussion in #2025.
Isn't formula-to-cask migration a result of optimizing for non-power users?
> .app that demands root privileges
To be fair, you can deny the privilege. Users do have a choice here.
In the specific case of keybase, personally I'd just keep building the keybase command line client from source. Not really a fan of kbfs, I tried it immediately after its initial announcement and only wanted to get it out of my system.
> My sense of the overall situation is that automatic formula -> cask migration is a mistake.
I don't like that either. But I don't think it's something I as an outsider could argue about. (I knew it "falls into the works-as-designed bucket" before you pointed that out.)
Meanwhile, abolishing `uninstall --force` is IMO both trivial and overwhelmingly positive; didn't expect this much pushback.
- not `uninstall --force`: worst case scenario: non power user messes with things beyond their pay grade; solution: `brew cask reinstall foo`;
- `uninstall --force`: worst case scenario: ???
> (getting into irrelevant details here)
I meant irrelevant details about the specific case of keybase. It is certainly possible to bork an installation in some other imaginary case, but I don't think it's the general pattern of what you could do with cask.
Also, ignore keybase and let's say mysql is being automagically migrated. Would you be so quick to eliminate every trace of the old installations?
> at the expense of the non-power user case and support burden.
Any proof for that? So far support burden seems to be coming from people who are not happy about the force uninstall.
Also not sure what is completely borked (getting into irrelevant details here). What's preventing people from running `keybase` with the absolute path instead of using the symlink?
> So we will just close those issue reports and tell people they're on their own at that point?
Those imaginary issues are easy to recover from. Fallout of an unwanted brew uninstall --force is not.
> Relinking the keg will overwrite those symlinks
You assume full responsibility when you run `brew link --overwrite`. Also there's `brew link --overwrite --dry-run` that tells you what's being overwritten, so that you can take a note of the original destinations.
> Sorry, but if the keg is still in place and opt-linked it is, by definition, installed. Hence, double installation.
Double installation of two non-equivalent packages in two separate, non-interfering package managers (if brew-cask can be called a package manager).
> They are not "harmless kegs" if the they're facilitating unsupported configurations.
1. `brew install foo`;
2. Formula `foo` removed;
3. (Optional) `brew unlink foo`.
Is this a supported configuration? Depends on your definition of "supported", but it is a routinely achievable configuration.
> What is the point of having a migration
I don't know what's the point of migration. Here I'm assuming migration (the installing cask part) as a given, and trying to minimize what I perceive as damage.
In the case of `brew upgrade`, the opt-link *has to* point to the new keg.
In the case of formula => cask migration (basically a formula removal as I argued above), there's no such hard constraint.
Formulae and casks are never equivalent, even if they install the exact same file. For one, there's `brew switch` but not `cask switch`, so force removing all kegs can do damage that's very complicated to recover from. (I still think any attempt to treat brew and cask / formulae and casks as equivalents is misguided and wishful thinking, but I'd rather not start another flame war from a very specific and IMO reasonable request upon which both sides could hopefully reach an agreement eventually.)
Basically, there's no double installation, but the legacy installation of a since-removed formula, and the installation (automatic one) of an overlapping cask. You don't force uninstall a user's kegs when you remove a formula. Likewise you shouldn't do so when migrating a formula to a cask, which is like passing through the event horizon of a black hole (vanishing from this world and appearing in another).
Users (especially power users) should get to decide what to do with harmless kegs.
> That sounds like a bug to me. If the migration fails it should be considered incomplete until it succeeds.
Sure. Doesn't fit in current logic though, where formula => cask migration only happens in `migrate_tap_migration` in `update-report.rb`, which only deals with changes seen in that update session.
> Also, if it's such an altenative universe, that raises the question why we bother with the migration at all.
Cask installer may write to the same files in `/usr/local`. It shouldn't hurt in most cases because overwritten files are no longer considered to be files belonging to brew, but still it could be messy. Which is why I'm suggesting an unlink. Otherwise brew stuff should be completely harmless IMO.
Also, if cask installer does not, say, write the same binaries to `/usr/local/bin`, unlinking things serves as a reminder that things have changed the next time the user tries to use what was installed by the formula. After all, I run `brew update` in a cron job and never check the logs unless errors occur, and I assume quite some people similarly run `brew update` routinely and non-interactively, which means we won't see the migration messages.
> How exactly will we know when to perform the migration...
It's only ever attempted once, when update-report detects the migration, unless you rewind the history. And I fail to see any harm of keeping the kegs, when the destination is an alternative universe only weakly linked by update-report.