Allow disabling checkver/autoupdate

[pratikpc]

We should allow adding a particular boolean variable using which we can temporarily disable checkver/autoupdate instead of deleting it manually and then bringing it back after fixes have been made.

[HUMORCE]

i am not sure of the performance differences between them, FYI.
maybe this should be a function of the excavator? skip specified manifests during excavator execution:

<main bucket>\excavator_skip.list

ffmpeg
git
...

[Luckz]

On a related topic, can we somehow define a custom version that won't be overwritten automatically by a lower, older (newest-on-Github) one?

For example, if I edit a manifest's "version":, and then run checkver.ps1 -app , it'll want to "update" to something lower (and presumably older).

[rashil2000]

It will not update to something lower. You can check the comparison function here -

Scoop/lib/versions.ps1

Line 107 in 1dbab1f

function Compare-Version {

[niheaven]

Unless you set force-update to TRUE.

[Luckz]

I have read the function several times, but the logic it expresses is ignored – at least as far as checkver is concerned.

Scoop/bin/checkver.ps1

Line 305 in 5602083

if ($ver -eq $expected_ver -and !$ForceUpdate) {

checkver will consider newer whatever release it finds, as long as it's not the one it already has.
An easy way to test is to change -eq to -le in that line, and it stops doing that. Obviously that's not a desired global change because a project might just switch to a completely different version string format, or not use conventional version strings whatsoever.
(Or maybe one could argue that auto updates should really only happen to well-behaved and thus larger version numbers, and that if needed the manifest should be specifically configured to allow for any exceptions?)

I'm asking this because, in a bucket, we wanted to have a custom version number as a placeholder until upstream updates. However, the github actions bot immediately undid it, downgrading to upstream's version. I tried to work around this in the manifest, but ultimately gave up when I realised the whole version logic doesn't affect this part of scoop.

Excavator also doesn't pay any attention to versions, as for example https://github.com/Calinou/scoop-games/search?q=betterjoy&type=commits shows ( https://scoop.r15.ch/games/mud-20211226-003001.log ) – seemingly a completely random downgrade to a year old release.

As an actually unrelated topic, it's seemingly true (I didn't know it beforehand) that Shovel just force-updates to whatever the available .json version in a bucket is, even if that's an older lower version, but that's scoop installer update behaviour rather than something related to the questions so far posed in this conversation. My beef lies with Github Actions.
@Ash258 's checkver has the same behaviour https://github.com/Ash258/Scoop-Core/blob/2c43379eadcd61c83995e7562fcf26a3038bfaf0/bin/checkver.ps1#L189 , and while Ash258 added a way to disable checkver / autoupdate without losing the configuration, my question is if there could be/should be/is a way to disable getting the manifest updated to an older (lower) version by innocent runs of Github Actions, Excavator, or manual checkver.ps1.

[niheaven]

The reason is, sometime software developers try to roll back their app version, and we need to decide whether to force users to update.

Scoop GitHub Actions tries to update all manifests to LATEST version, but for some websites that use CDN or A-B test, it may extract wrong version, and that's what we maintainers' responsibility to correct it (by temporally remove checkver, etc.).

[rashil2000]

I don't think we would need this. The only property that is checked during autoupdate is checkver - if it doesn't exist, the manifest won't be updated. So, just remove checkver instead of adding a new property.

Scoop/bin/checkver.ps1

Lines 91 to 93 in 7967905

	if ($json.checkver) {
	$Queue += , @($_.Name, $json)
	}