Make running "uninstaller" on updates optional

[ltguillaume]

For some reason that eludes me, the "uninstaller" script in a manifest is always run when an application is updated.

1. What is the reasoning behind this?
2. This can lead to the loss of user data without the user ever expecting it: especially in the case of the nonportable bucket, the "uninstaller" part of the manifest can run the actual uninstaller of the application, which takes all user data along with it. An example is https://github.com/ScoopInstaller/Nonportable/blob/master/bucket/spotx-np.json
3. I would suggest triggering the "uninstaller" part only on scoop uninstall. A separate "updater" part to be run during updates instead would be much more logical and would prevent the loss of user data.

I realize that some manifests work around this using e.g. if ($cmd -ne 'uninstall') { return }, but to me this should be handled at the manifest side, instead of using tricky workarounds.

[rashil2000]

I think this is a doable idea (introducing a new field). Would you like to work on it?

[ltguillaume]

ltguillaume@96ce058
Well, I'm not really proficient in PowerScript, but this should be it, I suppose...

1. Untested: there are probably some (automated) tests for this, too, and if so I'm sure you can point me to where this can be found/what to do.
2. I did not include pre/post updater hooks, as I don't see any use cases.
3. I didn't remove the "msi" part, even though it is deprecated and I couldn't find it in the buckets main, extras and versions. I'm not exactly sure if this would - if still used somewhere - uninstall the software first. Doesn't seem so from the arguments in the script alone. It's probably best to remove it only if it gets removed from e.g. uninstaller, too.

TODO:

1. Add to docs
2. Add to manifest template in e.g. https://github.com/ScoopInstaller/BucketTemplate/blob/master/bucket/app-name.json.template

[Ast3risk-ops]

The bucket example repo has some scoop test actions in it.

https://github.com/ScoopInstaller/BucketTemplate/tree/master/.github/workflows

[ltguillaume]

@rashil2000
Come to think of it, I think we can approach this a lot easier. See ltguillaume@f40a691

But I suppose there's something to say for a drop-in replacement hook at the place of post_uninstall in this case, in order to allow for some (clean-up) operations during updates, right before run_installer.

ltguillaume@806debc