Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Think about how to integrate the electron-builder delta update mechansim #73
Looks like the
There's a couple of questions to solve before discussing about any kind of integration.
First of all: why? I don't really see a reason to implement this in AppImageUpdate. They built their homebrew update system, and didn't seem to be interested in supporting AppImage specific features such as the update information. That's totally okay, don't get me wrong, but they have their own ecosystem, and "integrating" or even (re-)"implementing" would only help app store devs to update such AppImages. I am strongly opposed to implementing any special treatment for these AppImages, as they add a lot of complexity to the method that reads the update information, with little use for us, but a lot of maintenance overhead.
You remember that ticket? It was something based on the NSIS mechanism.
I would only consider integrating it with subprocesses at this point. Maintaining any other kind of implementation is too much work. Coding something based on NSIS's codebase or anything like that would be redundant. We should try to use the upstream code. Then, we don't have to react on changes in their code base, we just need to update some upstream tool or something alike.
According to the Electron dev who's implemented the cross-platform update mechanisms, they work similar to zsync, so I'd say they're more or like equally efficient.
That should be the first question. The current code base allows us to integrate other update systems. The question is more, what tools do Electron offer that could be used to implement these things?
@probonopd first of all, you need to find a (CLI) tool that can be used to perform an update on a given AppImage, or, if the former isn't possible, something like a parameter or environment varaible that needs to be passed to such an AppImage to cause an immediate update (although an external tool would always be less error prone).
Perhaps you should highlight the developer of the Electron update system here, so we can discuss the issue with them.
I don’t think that AppImage daemon should support electron updater format in general. For me is strange and comical — instead, electron updater should support ecosystem, not ecosystem :) But there is one big and stopper tecnical issue — our block map generator (see repo develar/app-builder) implemented in go and we can build app-builder executable very easy on any OS for any OS and arch. But zsync only on Linux.
Even this issue is not reported by user, but by you, author of AppImage.
Since appimage daemon is not preinstalled, we were forced to did the same as on Windows — use our own updater. We cannot preinstall AppImage daemon because it will lead to increased maintenance costs and end users questions (like what? Why app brings some another daemon to my system).
So that’s why currently electron-updater doesn’t support AppImage daemon.
@develar-vacation I think you got this wrong. This repository doesn't provide any kind of daemon. And there is no "AppImage daemon" -- there's only appimaged, which isn't responsible for any kind of updates, but only desktop integration (which works already with Electron AppImages).
Furthermore, desktop integration could've been performed completely independent of appimaged.
But, anyway, we are talking about giving people the ability to update AppImages built with Electron-builder.
As stated in my last comment, I wouldn't try to build your JS-based code at all. Instead, I'd rely on whatever tools you provide, given there's such tools. What we would have to do to support this, though, is to make Electron based apps embed a so-called update information. Since this is about using an external tool with a custom format, a static string would suffice.
Thank you @develar-vacation. I understand what you mean when you are saying "Packed into distributable format app should just works". And I completely share that vision.
"Linux people" in general want to "manage the system" all at once. The question is whether we want to (and can) support that in addition. So, use the mechanism inside the AppImage (that you have now) but in addition allow an optional external updater to keep all the AppImages in the entire system updated.
But now: Happy vacation!
@TheAssassin under “AppImage daemon” I mean some central solution, I don’t know exactly how do you call it.
Interesting, I am aware of “Update” context menu action for a single app, but I don’t know about centralized solution.
Electron builder uses old AppImage desktop integration script and all installed apps has vendor (exactly as it was in the provided script) prefix, so, it is easy to find all apps on a user machine.
So, we need to introduce some CLI hidden API, to call AppImage file with some arg to auto update, right?
Electron updater is a more feature rich (set of supported providers, e.g. GitHub and so on), there are known user custom private providers or customly configured SSL certs. That’s why I doubt that electron builder produced AppImage file can be updated externally (although I am agree that external updater will be better, it will not work for all and it will lead to maintaince hell).
This is an idea about creating a daemon using libappimageupdate, searching for updates for all AppImages on your system. It's nothing real, yet.
AppImageUpdate is a library and standalone application to update single AppImages. It would be nice if it was capable of updating any AppImage it is used for, therefore @probonopd suggested to add support for Electron's update mechanism. This doesn't mean we want to implement your mechanism, but we'd like to be able to trigger an update at any time.
libappimageupdate is also supported by a couple of app store apps. But you can't update anything Node-based right now, since those aren't built with support for the existing zsync-based mechanisms. Therefore I suggested to add support for external tools (like the CLI tool you mentioned), by adding a new type of update information.
Well, our update mechanism has a couple of features, too, e.g., there's a GitHub and Bintray provider. See https://github.com/AppImage/AppImageSpec/blob/master/draft.md#update-information.
How is the "Electron update information" embedded at the moment? Can it be read by reading a file inside the AppImage? If yes, it doesn't seem to be too problematic to build such an update mechanism. You could mount the existing AppImage (or we implement some kind of "--appimage-extract-file" parameter in the runtime), then read that file, and perform the update. The updater itself might even be contained in there.
When you're back from your vacation, feel free to join #AppImage on Freenode, and we'll work something out.
Enjoy the rest of your vacation!
See electron-userland/electron-builder#1138 (comment) (resources/app-update.yml)
So, in order to develop a "standalone" updater, you need to read that file, and run those routines. Seems doable.
@probonopd I'll consider my suggestion with the external tool seems like the way to go. We'll have to wait for the Electron team to release such a tool (as long as they're interested in better app store support through our libraries).
@develar-vacation where in the Electron-build code is appimagetool called? I'll send a PR with the missing parameter then.
We'll continue here as soon as the Electron tools are ready.