Issues with updater if ARM filenames have suffix, while x64 filenames don't

[RuiNtD]

Hello. I've encountered an issue with the GitHub updater on a few repos that release their ARM AppImages with suffix, but their x64 AppImages without a suffix; similar to this:

• AppName-1.0.0.AppImage
• AppName-1.0.0-arm64.AppImage

This causes Gear Lever to both incorrectly assume there's an update and potentially download an AppImage for the wrong architecture. This occurs, for example, with Kopia:

2024-07-11 15:00:59,839 INFO [AppImageProvider.py:263] Installing appimage: /var/home/ethan/Downloads/KopiaUI-0.17.0.AppImage
...
2024-07-11 15:09:07,072 INFO [UpdateManager.py:132] Downloading file from https://github.com/kopia/kopia/releases/download/v0.17.0/KopiaUI-0.17.0-arm64.AppImage

I believe the best solution for this would be to first check for URLs where all wildcards (*) match:

1. Update URL is set to https://github.com/kopia/kopia/releases/download/v*/KopiaUI-*.AppImage
2. Gear Lever checks for the latest tag name, which would be v0.17.0 (with a v) at time of posting
3. Gear Lever determines that the * matches 0.17.0 (without the v)
4. Gear Lever checks for the existence of https://github.com/.../v0.17.0/KopiaUI-0.17.0.AppImage
5. Gear Lever finds the file and uses it to update

Or, if it doesn't find the file, it proceeds with the previous logic.

[EccTM]

+1 on this issue, had it occur when updating IPTVnator.

Maybe if instead of globes, matching used regular expressions, we could then negate portions if required?

It's nowhere near as clean as the globes, but AppName-(.*)(?<!-arm64)\.AppImage would match only "AppName-1.0.0.AppImage", and not "AppName-1.0.0-arm64.AppImage", where (.*) would be our globe, and (?<!-arm64)would be matching for the clashing terms we don't want, like a wrong architecture in this case.

I could then use IPTVnator-(.*)(?<!-arm64|-armv7l)\.AppImage for example to avoid the ARM builds of IPTVnator.

[mijorus]

I could then use IPTVnator-(.*)(?<!-arm64|-armv7l)\.AppImage for example to avoid the ARM builds of IPTVnator.

Hi guys, thanks for the suggestions .
These regex work great, but they are a bit cumbersome, at least for the kind of simple user experience that I want to provide.

I'm currently exploring other options

[TickDracy]

I could then use IPTVnator-(.*)(?<!-arm64|-armv7l)\.AppImage for example to avoid the ARM builds of IPTVnator.

Hi guys, thanks for the suggestions . These regex work great, but they are a bit cumbersome, at least for the kind of simple user experience that I want to provide.

I'm currently exploring other options

While I would appreciate it if regex could be used (given the control you can have), I think @mijorus POV is right. Regex can be daunting and would make the experience too much technical.

I think the best option would be to have a field called ignore, where you can put blacklisted strings. In this case, the user could type arm. These keywords would be used as statements to ignore the wildcard check.

[mijorus]

I think the best option would be to have a field called ignore, where you can put blacklisted strings. In this case, the user could type arm. These keywords would be used as statements to ignore the wildcard check.

That's not so easy, is it? What if the app has "arm" in the name?

I should probably develop some "smart picker" which reads all the available files and picks the appropriate one based on the system architecture

[EccTM]

While I would appreciate it if regex could be used (given the control you can have)

Regex does actually work at the moment, it's just not documented as an option 📝

I know it does. But it shouldn't 🤣

[TickDracy]

That's not so easy, is it? What if the app has "arm" in the name?

You're right. I was thinking for the validation to be done between the two wildcards, but there's no guarantee that the string won't appear before, or that the user will have two wildcards.

[LautiLosio]

Hi, I'm glad to see that this issue has been identified and is being worked on. Has anyone found a workaround for now or at least a temporary solution to fix this problem?