Apps with self-updaters

[shoogle]

Aside: This mainly affects consumer applications so is arguably an issue for scoop-extras. I decided to post here since it could in principle apply to any app installed via any bucket.

TLDR: Many consumer applications have a built-in mechanism to install updates. These methods of "self-updating" can conflict with scoop's own update mechanism (via scoop update). Steps should be taken to prevent these conflicts from occuring. If necessary, either scoop update or the application's self-updater should be disabled to prevent users from getting into difficulties associated with installing via one method and updating via another.

Possible outcomes of installing an app via Scoop but updating via the app's own self-updater:

• The new version of the app overwrites the old version
  • scoop update does not overwrite old versions
• The new version is installed in the wrong location
  • e.g. C:\Program Files\... rather than ~/scoop/apps/...
• Installer scripts are executed
  • resulting in undesirable changes to the Windows Registry (among other things)

The latter two points are true for apps that update via WinSparkle framework, such as MuseScore. Installing a WinSparkle update is basically equivalent to running the installation Wizard, so the updated application is no longer associated with Scoop at all. If the user subsequently runs scoop update musescore (or scoop update *) then they could end up with two copies of the new version on the same machine.

Compare this situation with installing and updating applications in macOS via Homebrew Cask. Once a cask is installed it makes no difference whether the user updates it:

1. via Homebrew
2. via the application's own self-updater (e.g. via Sparkle for macOS)
3. by visiting the application website, downloading the new version, and manually dragging it to the Applications folder

The end result is always the same regardless of how the update is installed.

It may not be possible to achieve quite the same result on Windows. If that is the case then the user should be forced to choose between update mechanisms. Either scoop's update mechanism must be used exclusively with this application, or else it must be disabled in favour of the application's self-updater. It should not be possible to update via both mechanisms if doing so leads to conflicts or unexpected behaviour.

[quantuumsnot]

Yeah, some apps depend on the proper reg settings to work correctly, especially when called from other apps (ie clicking on link from mail client to open it in the browser using persist dir not the default one somewhere in C:\) - scoop doesn't take this into account and often the user is required to fix it by manually editing the registry. Doh

[shoogle]

@quantuumsnot,

some apps depend on the proper reg settings to work correctly

True. There are two ways to approach this issue:

Approach 1: "Scoop deliberately avoids making Registry changes in favour of a safer and more portable installation method that works without special user privileges. If you have an application that requires registry changes then arguably Scoop is not the right tool for you."

By this logic, Scoop should disable self-updaters and force people to use scoop update instead.

Approach 2: "Scoop is like Homebrew, and Homebrew makes a distinction between command line utilities (bottles) and consumer applications (casks). Homebrew keeps bottle separate from system utilities, but it puts casks in the system-wide applications folder along with the users' other apps. The end result of installing or updating a cask via Homebrew is indistingishable from installing or updating it via other means."

By this logic, Scoop should carry on using the portable method to install command line utilities, but for consumer applications scoop install and scoop update should just run the application's own installer.

Either approach is acceptable in my view, though it would be ideal if this choice could be left to the user somehow.

What is not acceptable, in my view, is the current situation where users install apps to one location with a certain set of permissions, but updates are potentially installed to another location with a different set of permissions.

[shoogle]

@Ash258, care to explain the thumbs-down?

[Deide]

Disabling an app's own updater should always be priority in my opinion, and I believe many manifests attempt to do this or advise that you do it.

[Ash258]

It is easy. You pointed problem but without solution or rather with solution which is not acceptable. You cannot force users to do anything. When application have autoupdate, then it is disabled (when it could be disabled; Ccleaner, conemu, zeal, aida, ..) and if user decide to change it there is anything, which could be done. You cannot just change it again.

If user will update application using installer it is their choice I do not see a reason to cover this use case. Windows applications are not as easy as under Mac Os. There is not easy way how to deal with it.

Since each application is doing differenet updates there do not exists any universal how to detect it and if do it would be resourece expensive or do it per application.

[shoogle]

@ash, not sure how I was supposed to get all that out from a thumbs-down emoji but nevermind. Thank you for responding so that I can address the points raised.

You pointed problem but without solution

How would we know this without discussing it first?

or rather with solution which is not acceptable. You cannot force users to do anything.

You can encourage or discourage users, either by having a documented policy, or by making particular actions easier or harder to do. It's true that you cannot prevent a determined individual from getting around your systems, but we are talking about accidental changes, not deliberate actions.

When application have autoupdate, then it is disabled (where it could be disabled)

So you do have a policy (perhaps it should be written somewhere) and you do try to enforce it! I was not aware of this so thanks for bringing it to my attention. This corresponds to "Approach 1" as I outlined above, and is a perfectly reasonable solution in my view.

Nevertheless, for some apps the self-updater is not disabled, and it would be good to have a solution for those cases.

if user decide to change it there is anything, which could be done. You cannot just change it again.

Of course, but I was talking about apps for which the updater is not disabled.

If user will update application using installer it is their choice I do not see a reason to cover this use case.

And yet you already try to cover it by disabling the updaters (where possible).

Windows applications are not as easy as under Mac Os.

This is unfortunately true, hence the need to look for a solution.

There is not easy way how to deal with it.

Let's not jump to conclusions.

Since each application is doing differenet updates there do not exists any universal how to detect it and if do it would be resourece expensive or do it per application.

True, but you might be able to tackle the low-hanging fruit. For example, we could reach out to the WinSparkle guys and ask them to build a disable mechanism into their updater framework. That would solve the problem for all WinSparkle apps and set an example for others to follow. It might even define a standard, such as don't check for updates if:

• The executable is run with an argument --no_updates, or
• A file no_updates exists in a specific location (e.g. next to the executable), or
• The enviroment variable NO_UPDATES is set.

The latter woul be similar to the NO_COLOR standard for disabling ANSI escape codes in terminal output.

Perhaps I was unfair (or unclear) when I described the current situation as "unnacceptable". I think the situation is indeed unacceptable, but I do not think it is scoop's fault. I would blame it on applications for not including a mechanism to disable updates, or on Windows for not providing a universal update mechanism or portable installation packages similar to macOS. Nevertheless, the situation is unacceptable and it would be great if Scoop could solve it somehow!

[r15ch13]

WinSparkle could be deactivated via registry: https://github.com/vslavik/winsparkle/wiki/Registry-Settings

[shoogle]

@r15ch13, interesting! That wouldn't help in Scoop's case though since you want to avoid making changes to the registry, right?

[quantuumsnot]

It is easy. You pointed problem but without solution

We're in scoop/issues so why not?

[NatoBoram]

One thing that would solve many problems with auto-updaters is moving the manifest file in a different place. This way, users would be able to let many self-updating apps update themselves whilst not breaking the Scoop integration.

Another thing that could be done is adding symlinks from known auto-updater hard-coded locations to the current folder. This sounds dirty, but when we think a bit about it, it would totally solve most problems with auto installers.

Apps with auto-installer could also be marked as nightly (or another flag that says they don't have versions) so that Scoop doesn't try to update it and to stop caring about versionned folders.

While all of this sounds a bit hacky, let's not pretend that apps with auto-updaters with hard-coded locations aren't hacky themselves.

[harvastum]

Idea: run scoop update in the background periodically (e.g. with Task Scheduler) and include a check for a newer version of the app in the shim. Then, prompt the user to update before actually running the app if a newer version is available. This might require extending the functionality of scoop status to allow checking the status of individual apps. This should not add much overhead if something like "isUpdateAvailable" would be added to the metatada somewhere.
It might seem imperfect, but given the chance to configure scoop this way, I would.

[rashil2000]

See also #3633

[erik9727]

I'm surprised to see this issue is approaching 3 years next week but the discussion hasn't converged to a solution yet. Does that mean this is a problem that's not affecting many people? How have you guys been dealing with it? I ask because I started using Scoop today and I'm a Firefox user and I can't get this issue out of my mind. While I understand I could run scoop update regularly I really think it would be nice if it had a better way of handling such cases.

[harvastum]

I did actually create a task in Task Scheduler, but only with scoop update. You could create one with a script to update particular (or all) apps too.

However, I just ended up removing the apps that have their own updaters and I use frequently from Scoop and use them separately. It is much less likely to cause a mess.

[NatoBoram]

How have you guys been dealing with it?

Personally, by using winget for the affected apps. It's not worth it to have Squirrel apps install themselves at two different places and to lose the manifest.json file every time the app is launched.

In the end, a mixture of winget and scoop gives the most flexibility possible. The end result is something like this.

I still think that these solutions are the best in Scoop's interest even if the developers aren't interested in them.

[rashil2000]

In the end, a mixture of winget and scoop gives the most flexibility possible. The end result is something like this.

As a maintainer of Scoop, I endorse this method, and personally use it. Some applications are just not meant to be managed by Scoop, so Winget (which runs the application's installer) wins over.

I'm going to close this issue - as mentioned before, we do disable autoupdates wherever possible (i.e. through the config file, or user registry key) during installation. What a user does afterwards is outside Scoop's control.