-
Notifications
You must be signed in to change notification settings - Fork 603
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow the appimage to update with appimageupdate #1316
base: main
Are you sure you want to change the base?
Conversation
Cemu has it's own auto-updater so there never was a need to support appimageupdatetool
Maybe @qurious-pixel can answer this |
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
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. |
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. |
@@ -34,9 +34,10 @@ chmod +x AppDir/usr/bin/Cemu | |||
|
|||
cp /usr/lib/x86_64-linux-gnu/{libsepol.so.1,libffi.so.7,libpcre.so.3,libGLU.so.1,libthai.so.0} AppDir/usr/lib | |||
|
|||
export UPD_INFO="gh-releases-zsync|cemu-project|Cemu|ci|Cemu.AppImage.zsync" | |||
export UPD_INFO="gh-releases-zsync|$GITHUB_REPOSITORY_OWNER|Cemu|latest|Cemu-*x86_64.AppImage.zsync" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The author specifically recommends against using latest
and suggests using continuous or just using version tags.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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: |
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. |
Done, and yeah something goes wrong when updating: Looks like zsync2 tries to download from the non existent |
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.