Skip to content
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

Self-update does not work with distributing binaries as zip #49

Open
slipher opened this issue Sep 4, 2019 · 1 comment

Comments

@slipher
Copy link

commented Sep 4, 2019

The updater's self-update functionality (replacing its own binary) does not work when it is launched from a zip file, as the binary path is some temp location.

We currently distribute the updater in a zip file, presumably due to the binary obesity (like 40M IIRC). One option would be try to find some compile flags to reduce the binary size, and then distribute the bare executable.

Another way would be to have the updater properly install itself - copy to the installation directory, create shortcuts etc. This would be a good idea in general since, assuming most users put the updater in the default "Downloads" folder or whatever, it is sketchy to have a non-single-use program located there.

@illwieckz

This comment has been minimized.

Copy link
Member

commented Sep 4, 2019

I've heard that's hard to reduce file size of QML binaries.

That's good you talk about having the updater properly installing itself. I'm thinking about this for weeks (I was just postponing that talk because of all other things I'm already thinking about).

For the next sentences I'll assume Linux (we would adapt for other OS):

Basically what I think is that the updater would install itself as ~/.local/share/unvanquished/base/updater at first launch and then run it and close the parent, and of course that path would be the updater to update in priority, and every time the original updater is started, whatever it is stored, it would start the one in ~/.local/share/unvanquished/base before doing anything else. Autogenerated shortcuts would point to the updater in that path, not the randomly downloaded one.

We may also try to replace the binary that is stored in the wild, but even if we fail to, that would not be a problem, starting an old updater will load the newer one even before trying to update.

That would fix the started-from-zip issue at the same time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.