Closed pratikpc closed 2 years ago
HUMORCE
commented
2 years ago 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:
\
ffmpeg
git
...
Luckz
commented
2 years ago 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
rashil2000
commented
2 years ago It will not update to something lower. You can check the comparison function here - https://github.com/ScoopInstaller/Scoop/blob/1dbab1fee8e8d775fc06248d2a3301d633c580a1/lib/versions.ps1#L107
niheaven
commented
2 years ago Unless you set force-update to TRUE.
Luckz
commented
2 years ago I have read the function several times, but the logic it expresses is ignored – at least as far as checkver is concerned.
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
commented
2 years ago 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
commented
2 years ago 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.
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.