-
Notifications
You must be signed in to change notification settings - Fork 1
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
Please do not wrap AppImages in an archive #1
Comments
Thanks to you for providing such useful AppImage project software to the communityI About the tar packaged it in a tar.xz, I did that in order to conserve the executable flag, so the person that downloads it doesn't has to chmod the file before executing it. About the binary delta updates, automated installation and discovery, how is that achieved? When I was repackaging with AppImageAssistant it threw an error message saying that the appimage already existed, so how are binary delta updates accomplished, also I noticed that using the wrapper script to generate an application icon displayed some decompressing message on the terminal when executing and the process seemed slower because it had to decompress the appimage twice, but I haven't analyzed the wrapper script that much so I may be wrong. By the way I wrote a pkgbuild for archlinux so is easier for archlinux users to install it https://aur.archlinux.org/packages/appimage-git/ And again thanks also for taking the time for the advice. |
Yes I understand the motivation but I think the price is too high to wrap an AppImage into an archive. Also future extensions of the AppImage ecosystem will rely on it not being wrapped in an archive.
For binary delta updates, see this (status: usable sample implementation available) For automated installation and discovery, see this (status: idea exchange and first tests underway)
That has nothing to do with binary delta updates; AppImageAssistant just doesn't overwrite an existing AppImage by default.
Please provide details. Extracting the icon is extremely fast because it only extracts the icon and not the entire content of the AppImage. |
Thats great, I missed that ones when researching the project. Thanks for pointing me to the right direction, the update mechanisms looks really convenient 👍
Read most of the article and all I can say is I would like to contribute developing some sort of web based appimage software center. Sounds like something fun to do and I believe AppImage is more easy to use and flexible than snaps and flatpak, the only missing piece is a central place where to publish appimages (at least images, description, download url, review system, etc...) so people can discover them easily as you wrote on the google plus post. Also a graphical interface to interact with the web based database of apps. |
I have started building the infrastructure needed for a "web based appimage software center": That being said, I cannot add this application to it because I cannot find a download link for the AppImage. It would be nice if for releases and possibly also for continuous builds, the AppImage could be downloaded to the GitHub Releases page. Personally I am using https://github.com/probonopd/uploadtool for this. Could easily be adapted to your needs. References: |
Thanks for providing an AppImage.
Please do not wrap AppImages in an archive like a
tar.xz
file since they are already compressed. By not wrapping AppImages in an archive you will have additional benefits in the future, like easy binary delta updates, automated installation, discovery via application directories, etc.The text was updated successfully, but these errors were encountered: