Self-updating AppImages about appimageupdate HOT 12 CLOSED

Therefore, a binary called AppImageSelfUpdate (a modified variant of the new GUI AppImageUpdate) has been implemented, making self-updates as easy as calling a subprocess.

What I still can't wrap my head around is why we need a separate binary for this rather than just using the regular libappimageupdate or AppImageUpdate, depending on how deeply the application author wants to integrate the update functionality into the app's look and feel.

from appimageupdate.

What I still can't wrap my head around is why we need a separate binary for this rather than just using the regular libappimageupdate or AppImageUpdate, depending on how deeply the application author wants to integrate the update functionality into the app's look and feel.

The idea is to provide this functionality to any application whatever language they use. An Electron or Python based app can't "just use" libappimageupdate. Also, libappimageupdate doesn't provide self-updating, it's AppImageSelfUpdate which implements this with just a few library calls (not to mention it's really easy to call a subprocess via exec() (any language has an equivalent of this), but adding a dependency on another library usually is quite problematic). AppImageSelfUpdate provides a UI for this already that looks exactly the same as the main UI, so that saves quite some work as well.

Nobody stops you from using libappimageupdate directly, but the easiest way of providing this functionality is just to have a separate binary that is bundled in the AppImage.

from appimageupdate.

Couldn't we have AppImageUpdate do that as well (dual use: standalone vs. embedded inside another AppImage)?

from appimageupdate.

No, because AppImageUpdate should update other AppImages as well when being packaged as an AppImage itself. AppImageSelfUpdate won't be packaged as an AppImage therefore.

from appimageupdate.

Why not put AppImageUpdate.AppImage into the AppImage that is supposed to be (auto) self updating?

from appimageupdate.

Because then you'd obviously have set the relevant environment variables to AppImageUpdate's AppImage.

Also, being automagic about this by detecting whether AppImageUpdate is packaged into another AppImage or not could lead to a lot of confusion.

As I'm using the same file to generate both applications, little effort is required to maintain both in parallel.

from appimageupdate.

I'm not sure I understand. Whenever the payload application thinks it would be a good idea to check for updates, then it could exec AppImageUpdate?

from appimageupdate.

That's the idea. You call AppImageSelfUpdate --update-check (not the final API, just so you get the idea) to see whether an update is available, the exit code contains that information. Eventually, you just exec(...) AppImageSelfUpdate (to close the current application, too), and AppImageSelfUpdate will update and re-open the current AppImage.

from appimageupdate.

This is a lot easier to integrate than building and linking to libappimageupdate, as it just needs a few calls to the standard library of the current programming language.

from appimageupdate.

This is what Subsurface currently does (independently of AppImage):

from appimageupdate.

I updated the page with a more exhaustive description how to use the existing software to self-update AppImages in a proper way, highlighting potential cavecats. @probonopd please review.

from appimageupdate.

For self-updates, users may now either bundle AppImageUpdate and call it with $APPIMAGE, or use libappimageupdate directly.

from appimageupdate.