Should an issue not be opened for a bug if it was resolved by using the --force flag?

[ejenk0]

Output of brew config

HOMEBREW_VERSION: 5.0.16
ORIGIN: https://github.com/Homebrew/brew
HEAD: a0bd077aafa7dcdf3562fa39afd0eb70f36af08c
Last commit: 3 days ago
Branch: stable
Core tap JSON: 05 Mar 02:21 UTC
Core cask tap JSON: 05 Mar 02:21 UTC
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_DOWNLOAD_CONCURRENCY: 16
HOMEBREW_FORBID_PACKAGES_FROM_PATHS: set
HOMEBREW_MAKE_JOBS: 8
Homebrew Ruby: 3.4.8 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.4.8/bin/ruby
CPU: octa-core 64-bit arm_firestorm_icestorm
Clang: 17.0.0 build 1700
Git: 2.50.1 => /Library/Developer/CommandLineTools/usr/bin/git
Curl: 8.7.1 => /usr/bin/curl
macOS: 26.3-arm64
CLT: 26.2.0.0.1.1764812424
Xcode: N/A
Rosetta 2: false

Output of brew doctor

Your system is ready to brew.

Description of issue

Hello,

I had an issue uninstalling a cask, where brew said it was not installed, even though it was listed in brew list and appeared in my applications.

I went to make an issue on github, and saw the "I have retried my command with --force." check.

This resolved my issue, in that I was able to uninstall the cask, but doesn't this still indicate that there is some issue with the specific cask I was trying to uninstall, or with homebrew? The checklist seems to indicate that since my problem is resolved, I should not open an issue, but it feels wrong...

Thanks for your advice!

[ejenk0]

As it turns out, my issue might still be an issue... Although the cask was removed from my brew list, it is still in my Applications folder an launchable...

I think with this further information, it is clear that I should open an issue (provided I have tried the other remedies), but I think my original question is still important and less clear.

[gromgit]

[FullDisclosure: not a Homebrew maintainer, just someone with more understanding about package management complexities than I'd care to.]

The likely reason "fails even with --force" is one of the conditions: uninstallation follows a Homebrew script that's stored with your installation, and is therefore correct at the time it was installed, but may not be by the time you uninstalled it, particularly if the script uses directives that have been disabled in the meantime.

The installation state that Homebrew typically expects can also change from time to time, so there may be situations like what you encountered, when different Homebrew commands may look at different subsets of installation state and draw different conclusions.

Problem often surface with auto-updated casks, where the app updates itself at run-time, so Homebrew doesn't do so unless you explicitly brew upgrade --greedy. By the time you uninstall that cask, the app may be at its latest version, but months or even years may have gone by without Homebrew updating the installation (and therefore its installation state and/or uninstall script).

I believe there was a recent PR that tries to address at least some aspects of this situation, but Homebrew maintainers are in a better position to explain that part.

[ejenk0]

@gromgit

Thanks for your answer! You've helped me understand the --force issue a bit better.

Tangential question: Can I avoid this problem by disabling (or somehow externally forbidding) things auto-updating themselves? I install absolutely everything on my Mac via brew, and I run brew upgrade --greedy fairly regularly already. If I do this, I assume brew will always have a recently generated uninstall script to use?

If anyone is curious, the problematic cask was adobe-acrobat-reader (what a surprise...).

[gromgit]

Tangential question: Can I avoid this problem by disabling (or somehow externally forbidding) things auto-updating themselves?

Not really, the problem lies with Homebrew installation state, which is separate from the app's installation state.

I install absolutely everything on my Mac via brew, and I run brew upgrade --greedy fairly regularly already. If I do this, I assume brew will always have a recently generated uninstall script to use?

Yes in theory, though it's always possible that uninstallation of the latest-n-greatest app version has changed somewhat from what's currently in the latest cask script. This requires humans to recognise it and change the cask accordingly; there's no magic wand I know of that can be waved to address this, and even the app's own developers may fail to update their preferred uninstaller correctly.

If anyone is curious, the problematic cask was adobe-acrobat-reader (what a surprise...).

% brew info adobe-acrobat-reader
==> adobe-acrobat-reader ✘: 25.001.21223 (auto_updates)
                                          ^^^^^^^^^^^^

Well there's your problem. 😆

[ejenk0]

Ah alright. Thanks again for your detailed response!

Seems like this is an issue I'll just have to remember and deal with accordingly when it arises again. Good to know!

Best of luck with everything 😁