AppImage support

[probonopd]

Hi, would you be interested in adding AppImage support?

https://github.com/probonopd/AppImageUpdate
https://github.com/AppImage/AppImageSpec/blob/master/draft.md#update-information

@TheAssassin has been thinking about making the underlying https://github.com/probonopd/zsync-curl into a library that could eventually be consumed by a Qt updater tool like yours.

[Skycoder42]

Hi. I think this would be a nice idea, but kinda needs a complete rewrite. AutoUpdater was created especially for the Qt maintenancetool. However, since it's split up into 2 parts (core and gui), It should be possible to "seperate" them enough to make it possible to use the gui with any backend update mechanism.

I'm new to AppImage, so I don't think it would be a good idea to do this myself. However, if you are interested, I could work out an "interface" to replace the core library by a plugin system, making it possible to implement multiple updater backends, including the AppImage variant.

I hope I was able to express my idea, and I'd like to hear your thoughs on this.

[probonopd]

Hi @Skycoder42 yes this makes sense. Perhaps @TheAssassin will chime in here too.

[Skycoder42]

Okay, I have been checking the code, and modifying the core library to use plugins for the actual update checks is possible. I am willing to make those changes, but it would be nice if someone would agree to create the plugin for appimage updates.

The important part here is: AutoUpdater does not update. Instead, it queries the updater of Qt whether there are updates, and starts it if required.

To make this work with the AppImage approach, we would either have to bundle your updater with the library (AppImage inside AppImage?), or extend the possibile functionality of autoupdater to include the updating itself. For the latter, I will not do that, but I would accept pull-requests.

Following the "embedding" idea - it would be possible to include the updater image as resource, and extract it to a cache location. I personally think this is a more pratical, but less efficient approach.

Tell me would you would be willing to contribute to this, and which approach you would prefer.

[probonopd]

AutoUpdater does not update. Instead, it queries the updater of Qt whether there are updates, and starts it if required.

In this case, it could query the AppImageUpdate tool

extend the possibile functionality of autoupdater to include the updating itself. For the latter, I will not do that, but I would accept pull-requests.

I think that would be the way to go. We will change our tools to be libraries that could be easily consumed from a Qt application.

Following the "embedding" idea - it would be possible to include the updater image as resource, and extract it to a cache location

Not needed. AppImageUpdate can update a running AppImage, even if AppImageUpdate itself is contained within the same AppImage. So it can "update itself".

@TheAssassin or I will ping you once we have something usable in place.

[TheAssassin]

TheAssassin "chiming in".

Yes, I plan to make zsync_curl a library. But to make that maintainable, we should rewrite zsync_curl based on the existing C libraries, as the current code is buggy and... yep, weird appears to be the right word to describe it.

I'd like to rewrite zsync_curl in C++, and make that a library by default. Then, I'd write multiple programs that rely on that library:

• zsync_curl commandline tool
• AppImageUpdate CLI
• AppImageUpdate GUI

We can add QtAutoUpdater to that list.

The plan is to get an easy-to-use library with a clean API. E.g., zsync::updateFile("https://ghj.kl/mno/p.AppImage", "p.AppImage"); or something comparable. Also, I plan to (of course) add a legacy C API (a pretty naive wrapper for the C++ methods).
C++ should be used IMO to make it easier to work with these kinds of parsers etc. Although I'd be open to a C library and C++ frontends, too.

I think that sounds like a good plan. Help welcome. Probably a great opportunity to get to learn how to use C and C++ together.

If someone is interested, we could even rewrite libzsync and even librcksum if we find a contributor for that. But for now, it's not necessary. Just update a few integers to use int64_t etc. to support bigger files and we're good to go.

See https://github.com/probonopd/zsync-curl/tree/master/src for more information.

[Skycoder42]

Hi,

I create a new branch, plg_refactor. This branch contains a refactored updater library based on plugins. You can now fork/clone it to create a plugin for an appimage updater.

The new code is documented, but not published yet, you can create it by running qmake && make doxygen. You will need python 3 and doxygen installed.

To build the libraries, qpm is needed (http://qpm.io/). Run cd src/3rdparty && qpm install. After that, the project should be compilable.

The classes that need to be implemented are UpdaterPlugin and UpdateBackend. The implementation for the installer framework is located at src/plugins/updaters. Create a similar project in the same directory for another plugin.

If you need any help with the library, feel free to ask.

[probonopd]

(moved to https://github.com/antony-jr/GHReleaseBridge/issues/1)

[antony-jr]

[moved to #14]