Make launchctl service removal sudo failures non-fatal

[mio-19]

Verification

• This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

Provide a detailed description of the proposed feature

Currently, Homebrew attempts to remove launchctl services, which requires root privileges. However, users who install Homebrew without root access or prefer not to enter their admin password every time may find this behavior inconvenient.

What is the motivation for the feature?

Right now, Homebrew tries to remove launchctl services, but that needs root access. If you don’t run Homebrew as root (or just don’t wanna type your password every time), this gets annoying fast.

How will the feature be relevant to at least 90% of Homebrew users?

I am not sure

What alternatives to the feature have been considered?

I haven't

[MikeMcQuaid]

@mio-19 Which command(s) specifically are you seeing this behaviour with?

To help us debug this issue can you explain:

• What you were trying to do (and why)
• What happened
• What you expected to happen
• Step-by-step reproduction instructions (with as minimal input data as possible)

[mio-19]

@mio-19 Which command(s) specifically are you seeing this behaviour with?

To help us debug this issue can you explain:

• What you were trying to do (and why)
• What happened
• What you expected to happen
• Step-by-step reproduction instructions (with as minimal input data as possible)

It either happens during an upgrade when a cask is upgraded or uninstalled. Many casks, such as "visual-studio-code", have defined launchctl: "com.microsoft.VSCode.ShipIt". When I explicitly ask Homebrew to upgrade them, it prompts me for a password to remove the launchctl entry.

On a normally supported Homebrew installation, I might be too lazy to type my password for sudo, as it is not actually needed to remove launchctl during an upgrade. However, on an “Untar Anywhere” (unsupported) installation on a machine where I don't have access to an administrator account, it is not possible to use sudo to remove launchctl and resulted in failed commands.

[MikeMcQuaid]

On a normally supported Homebrew installation, I might be too lazy to type my password for sudo, as it is not actually needed to remove launchctl during an upgrade. However, on an “Untar Anywhere” (unsupported) installation on a machine where I don't have access to an administrator account, it is not possible to use sudo to remove launchctl and resulted in failed commands.

What happens if you just hit enter instead of your command in these cases?

We're unlikely to spend much time trying to improve the unsupported case.

[mio-19]

This is what happen if I just hit enter instead of typing my password when upgrading casks with launchctl
After this microsoft-edge wasn't upgraded as "uninstall" failed

[MikeMcQuaid]

@mio-19 ok so the request is that if it fails this isn't fatal?

Did you need sudo to install microsoft-edge?

[mio-19]

@mio-19 ok so the request is that if it fails this isn't fatal?

Did you need sudo to install microsoft-edge?

Yes microsoft-edge is not a good example as it needs sudo to upgrade anyways. google-chrome might be a good example
If removing launchctl fails, it isn't fatal. Also it would be great if I can tell homebrew just don't bother removing launchctl services when upgrading casks

[MikeMcQuaid]

@mio-19 Do you have any examples that don't require sudo to install but do to uninstall?

[mio-19]

@mio-19 Do you have any examples that don't require sudo to install but do to uninstall?

google-chrome might be an example. It doesn't require sudo to install but require sudo to remove launchctl

[MikeMcQuaid]

Ok, thanks @mio-19. I've updated the issue title here to what I think we should aim for. It shouldn't be an option but just make this operation non-fatal in this situation.

[KyriosGN0]

i am also running into this issue with perimeter81 cask, to me even when i am attempting to run with root, it fails with operation not permitted

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.