Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Teamviewer cask uninstall should act differently in macOS Catalina #118316

Closed
6 tasks done
sataset opened this issue Jan 28, 2022 · 13 comments
Closed
6 tasks done

Teamviewer cask uninstall should act differently in macOS Catalina #118316

sataset opened this issue Jan 28, 2022 · 13 comments
Labels

Comments

@sataset
Copy link
Contributor

sataset commented Jan 28, 2022

Verification

Description of issue

Teamviewer cask uninstallation should be blocked if done through homebrew CLI on macOS Catalina (and maybe other versions?) due to the bug which is actually listed on cask info page:

WARNING: teamviewer has a bug in Catalina where it doesn't deal well with being uninstalled by other utilities.The recommended way to remove it is by running their uninstaller under:

Preferences → Advanced

This bug is critical as it makes macOS not load.

I needed to go through the recovery process, install teamnviewer back again and uninstall everything through TeamViewer uninstaller to make sure everything is done correctly. This however does not remove homebrew installed package entry.

Command that failed

brew uninstall teamviewer

Output of command with --verbose --debug

null

Output of brew doctor --verbose

null

Output of brew tap

null
@miccal
Copy link
Member

miccal commented Jan 28, 2022

Please see #76829

Besides the caveat message, there is nothing more we can really do here except for removing the Cask entirely.

@miccal miccal closed this as completed Jan 28, 2022
@carlocab
Copy link
Member

This bug is pretty bad, though. Can we make brew uninstall teamviewer do nothing on Catalina, at least?

@miccal
Copy link
Member

miccal commented Jan 28, 2022

@carlocab no -- the install and uninstall are linked. The only way to fix this would be to not allow this Cask be be installed on Catalina in the first place.

@carlocab
Copy link
Member

I think that's reasonable given the risks of bricking someone's system. It seems recoverable if you have some experience with macOS, but I'm not comfortable relying on that.

@miccal
Copy link
Member

miccal commented Jan 28, 2022

True, but changing it now would cause an issue for any user on Catalina who has this currently installed via Cask.

I think this is one of those cases where we are damned if we do and dammed if we don't.

It would be really nice if user's actually read our caveats :)

@carlocab
Copy link
Member

The cask specifies a bunch of things to uninstall, though:

uninstall delete: [
"#{staged_path}/#{token}", # This Cask should be uninstalled manually.
"/Applications/TeamViewer.app",
"/Library/Preferences/com.teamviewer.teamviewer.preferences.plist",
],
pkgutil: [
"com.teamviewer.remoteaudiodriver",
"com.teamviewer.teamviewer.*",
],
launchctl: [
"com.teamviewer.desktop",
"com.teamviewer.Helper",
"com.teamviewer.service",
"com.teamviewer.teamviewer_desktop",
"com.teamviewer.teamviewer_service",
"com.teamviewer.teamviewer",
],
quit: "com.teamviewer.TeamViewer"
zap trash: [
"~/Library/Application Support/TeamViewer",
"~/Library/Caches/com.teamviewer.TeamViewer",
"~/Library/Caches/TeamViewer",
"~/Library/Cookies/com.teamviewer.TeamViewer.binarycookies",
"~/Library/Logs/TeamViewer",
"~/Library/Preferences/com.teamviewer.TeamViewer.plist",
"~/Library/Preferences/com.teamviewer.teamviewer.preferences.Machine.plist",
"~/Library/Preferences/com.teamviewer.teamviewer.preferences.plist",
"~/Library/Saved Application State/com.teamviewer.TeamViewer.savedState",
]

What happens if we wrap that whole block in unless MacOS.version == :catalina?

@miccal
Copy link
Member

miccal commented Jan 28, 2022

I did not know we could do that in Cask -- worth a try, though.

@sataset
Copy link
Contributor Author

sataset commented Jan 28, 2022

There are other casks that basically work "one-way" only (e.g. windscribe).

Maybe these kind of casks should not be added or some general rule should be applied for all casks? Because it basically breaks the way homebrew / package managers work.

P.S.: I am not really familiar with Ruby but looking at .rb script it seems possible to just remove links or make it dummy? After dummy uninstall it is possible to catch user's attraction to caveat message during uninstallation process as it will not delete the installed application.

P.P.S: I am not usually missing caveats but in that case I noticed it is hard to see due to:

  • Caveat log message placement (update, caveat, download, install). Usually I am seeing warning messages after installation so it is hard to miss them.
  • Terminal window height: as caveat log message is not printed in the end it requires user to scroll almost all the way up to the caveat message.

@carlocab
Copy link
Member

The caveats should be printed at the end. If that's not happening for casks, that's a bug.

@sataset
Copy link
Contributor Author

sataset commented Jan 28, 2022

That is exactly what happened during the process that I have listed in the issue description (brew install teamviewer back, uninstall through GUI).

Spoiler with screenshot

image

@sataset
Copy link
Contributor Author

sataset commented Jan 28, 2022

What happens if we wrap that whole block in unless MacOS.version == :catalina?

@carlocab, I think it is preferrable to use application's integrated uninstaller when possible? Correct me if I am wrong.

@carlocab
Copy link
Member

That is exactly what happened during the process that I have listed in the issue description (brew install teamviewer back, uninstall through GUI).

That's a bug. Please report this at Homebrew/brew.

@carlocab, I think it is preferrable to use application's integrated uninstaller when possible? Correct me if I am wrong.

You're not wrong. Please see #76829 and #24377.

@miccal
Copy link
Member

miccal commented Jan 30, 2022

#118326

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 2, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants