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

AppImage takes longer to start since switching to velopack #29810

Closed
peppy opened this issue Sep 9, 2024 · 6 comments
Closed

AppImage takes longer to start since switching to velopack #29810

peppy opened this issue Sep 9, 2024 · 6 comments

Comments

@peppy
Copy link
Member

peppy commented Sep 9, 2024

As reported by at least one user

Likely related to xz being used instead of zstd:

https://github.com/AppImage/appimagetool/blob/81ee1db4946780292cd046d4c269a9b4fd7bc29d/src/appimagetool.c#L139-L141

@caesay
Copy link

caesay commented Sep 22, 2024

I tried switching the default compression to zstd, but it broke in my test environment (failed to start). I then found several other threads discussing how xz and gzip are really the only two widely supported compression formats and there are many circumstances in which the others break.

So, I made compression configurable in velopack/velopack#238

Feel free to switch to zstd if you understand that it may not work for some people.

@smoogipoo
Copy link
Contributor

smoogipoo commented Sep 25, 2024

Thanks @caesay.

failed to start

Actually, I was already working on this in a branch (https://github.com/smoogipoo/velopack/commits/use-zstd/) and reached the same issue.
Likely the reason it failed to start is because Velopack uses AppImageKit which is the old cross-platform toolkit that doesn't support zstd (see: AppImage/AppImageKit#1091), as compared to appimagetool that is the intended upgrade path which does support it but is not cross-platform. That issue prevented me from going further with this, because the Velopack wiki states that Linux can be cross-compiled to.

In the case of the current tool, it will appear to work but fail to decompress because it can't recognise the zstd header. Unfortunately, using zstd with your change is not going to work for any system. It was working for us previously because we were using appimagetool.

I would suggest reverting your change, as using zstd would break installations on the next update.

@caesay
Copy link

caesay commented Sep 25, 2024

I'm surprised by this. 'appimagetool' seems to use the same runtimes as appimagekit? (https://github.com/AppImage/type2-runtime) And we don't use these tools directly, we build the AppImage by creating a squashfs filesystem manually and prepending the runtime so that we can also build packages on windows.

@caesay
Copy link

caesay commented Sep 25, 2024

I stand corrected, they do have different runtimes. So I think fixing this up will just require replacing our runtimes with those available here https://github.com/AppImage/type2-runtime/releases

@smoogipoo
Copy link
Contributor

Also, I used the default params for squashfs for zstd (https://linuxreviews.org/Squashfs#mksquashfs_.28squashfs-utils.29) which were also changed for appimagetool in AppImage/appimagetool#65

I'm not sure how big of an issue that is, just thought I'd be consistent with what's worked so far 😛

@caesay
Copy link

caesay commented Sep 26, 2024

zstd images appear to be working properly in https://github.com/velopack/velopack/releases/tag/0.0.630-g9c52e40

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants