Allow the appimage to update with appimageupdate

[Samueru-sama]

This change allows delta updates with appimageupdatetool

I noticed that there was old release info in the build script, but checking the releases it seems it never got implemented?

Also was there a specific reason to be using mkappimage instead of appimagetool? as far as I know the only difference used to be that mkappimage was pulling the static runtime, but that is something that now appimagetool does as well, so functionality wise there is no difference I think.

Note that ideally the zsync should be released on the latest release and not in the pre-releases, else the entire update info and the release tags would need to be changed to allow updates on pre-releases.

[Exzap]

Cemu has it's own auto-updater so there never was a need to support appimageupdatetool
Of course more options are always nice, but the problem I see is that we currently have an UI option that influences which releases are selected for updating (two channels: releases only or releases+pre-releases). I am not sure how we would handle this with something like appimageupdatetool. We could maybe just ignore the UI option and always only update to releases and skip pre-releases, but I am not sure this is doable with our setup. Initially all new releases are marked as pre-release so we can't differentiate at build time.

Also was there a specific reason to be using mkappimage instead of appimagetool?

Maybe @qurious-pixel can answer this

[Samueru-sama]

Cemu has it's own auto-updater

All the years I've been using Cemu and never noticed there was an auto-updater 😅

Although I just tested it and I get this error and the original appimage gets named .backup, I'm not sure if the new file was downloaded somewhere else.

We could maybe just ignore the UI option and always only update to releases and skip pre-releases, but I am not sure this is doable with our setup. Initially all new releases are marked as pre-release so we can't differentiate at build time.

The UI option doesn't have to be ignored, just that when using appimageupdatetool, it will only update to stable releases, to get pre-releases the user woud need to either manually download it or use the UI to get it.

Something good of appimage update is that the user doesn't have to do the update by opening the application and it can also replace the existing appimage with its original name (which is useful when you have the appimage in PATH) and does a delta update meaning that it doesn't download the entire appimage to update it.

And no changes have to be done to the build process, just that if you want to support appimageupdate with pre-releases then the release tags would need to be changed, else it will always pick the latest stable release instead.

[qurious-pixel]

For appimageupdate, the .zsync2 file has to be hosted to a known location. This can be the github releases page or a download webpage, but that info gets embedded into the appimage (which currently it is not).

The most recent update to 2.1 has changed somethings, so it may be wiser for me to wait until 2.2 to see how the update broke.

[qurious-pixel]

The author specifically recommends against using latest and suggests using continuous or just using version tags.

[Samueru-sama]

Are you sure? Because I had this issue: AppImageCommunity/AppImageUpdate#233

I originally tried to get it working but couldn't because Cemu used to release as pre-releases with varying tag names, I tried continuous, ci, testing, etc and none worked.

Now Cemu is going to make more stable releases instead of making pre-releases, so I rebased my changes and made this PR.

[Samueru-sama]

For appimageupdate, the .zsync2 file has to be hosted to a known location. This can be the github releases page or a download webpage, but that info gets embedded into the appimage (which currently it is not).

The most recent update to 2.1 has changed somethings, so it may be wiser for me to wait until 2.2 to see how the update broke.

Hi, I don't know what you meant in the last phrase, what do you mean by wait to see how the update broke? you mean the internal update mechanism that Cemu has?

Anyway, how the release is setup right now it zsync works, you can see it in my fork:

https://github.com/Samueru-sama/Cemu/releases/tag/v2.1

[qurious-pixel]

From your error message, I had assumed something broke due to the naming convention change from Cemu-2.0 to Cemu-2.1. I had to make some changes to scripts I manage, and flatpak maintainer did too. But the update still works from Cemu-2.0 to Cemu-2.1.

I also use appimageupdate for projects that do not self-update. Your changes appear to work including the new appimagetool, which recently switched to fuse3.

Can you do a version 2.2 on your repo? Cemu-2.0-7 update fails.
Version 2.1 updates, but yields the last commit from your test6 branch, as version identifier. Cemu-adf0abf-x86_64.AppImage

[Samueru-sama]

From your error message, I had assumed something broke due to the naming convention change from Cemu-2.0 to Cemu-2.1. I had to make some changes to scripts I manage, and flatpak maintainer did too. But the update still works from Cemu-2.0 to Cemu-2.1.

I also use appimageupdate for projects that do not self-update. Your changes appear to work including the new appimagetool, which recently switched to fuse3.

Can you do a version 2.2 on your repo? Cemu-2.0-7 update fails. Version 2.1 updates, but yields the last commit from your test6 branch, as version identifier. Cemu-adf0abf-x86_64.AppImage

Done, and yeah something goes wrong when updating:

Looks like zsync2 tries to download from the non existent Cemu-adf0abf-x86_64.AppImage that was renamed to 2.2?