AppImage version

[RafaelLinux]

Please, pack an AppImage version. Is the easier and clean way to let linux user to try your application.

Thank you

[xandaaah]

This won't work out. Appimages are not meant for CLI apps, they are meant for graphical ones.

[RafaelLinux]

Appimages of CLI apps are totally possible and the appimage runtime provides the env variable ARGV0 which contains the name of the binary/symlink it was launched with, which means you can have your own "busybox" with the appimage runtime and have several CLI utilities in one.

See imagemagick, nvtop or this appimage of android tools that I have.

Since distrobox is a shell script, all that is left is bundle podman which I think there are static bins of.

This information is really relevant. I was unaware of that possibility. Every now and then, AppImages surprise me by having many more possibilities than the ones that are usually used when packaged in that format. The last one I knew about was “auto-update”, which only one of the AppImage I use implements.
But your information brings even more flexibility still. I won't get tired of seeing more and more virtues in AppImage.

[Samueru-sama]

The last one I knew about was “auto-update”, which only one of the AppImage I use implements.

AppImages are meant to be updated using appimageupdate which provides delta updates (that is it doesn't download the entire appimage again for an update).

I know the go-appimage daemon supports it, as well as AM has support for it.

If you want to know if an appimage supports appimageupdate, just check where the appimage is published if there is a .zsync file, which most do.

[RafaelLinux]

AppImages are meant to be updated using appimageupdate which provides delta updates (that is it doesn't download the entire appimage again for an update).

I know the go-appimage daemon supports it, as well as AM has support for it.

If you want to know if an appimage supports appimageupdate, just check where the appimage is published if there is a .zsync file, which most do.

Some time ago I tried to use the update application that you mention, but for me at least, that AppImageUpdate functionality did not work, and I deduce that it is because they do not implement the coding that you mention.

However, the AM that I mentioned, did not require to have any AM manager. Out of all the AM's I use (over 30) that one specifically surprised me one day because when I launched it, it asked me if I wanted to update it and I told it to do so. I don't know the process it did in the background, but it updated. That is, if I'm not mistaken, it did not use the AppImageUpdate service that it is possible to have in running background performing.

Since then, except for that app, all of them I have to update with the typical process of going to the official page, downloading, etc.
Now I am left with the doubt and I ask you, after having installed AppImageUpdate, if I want to update an AppImage that I have in the “Applications” folder. Does AppImageUpdate warn of an update when launching one of these applications or is it always with the contextual menu?

[Samueru-sama]

What do you mean by of all the AMs? There is only one and technically appman but that one got merged into AM as well.

AM/appman install appimages in a location of your choosing, AM puts them in /opt while appman anywhere in $HOME you want, it also automatically places the .desktop and icon in their places and updates them when you run am -u and if you have appimageupdatetool installed it will update with appimageupdatetool.

if I want to update an AppImage that I have in the “Applications” folder. Does AppImageUpdate warn of an update when launching one of these applications or is it always with the contextual menu?

In that case I think the go-appimage daemon does send a notification about new updates, not sure.

[RafaelLinux]

"All the AM's" means that when I used one of the AppImages managers (AM's) one of them (I don't remember if AppimageUpdate) required all my AppImages to be in a folder called “Applications” under my user. I didn't like the idea very much, but I already keep that folder and that's where I download each new AM or its updates. However, none of the managers I tried updated any of the many AppImages I had downloaded.

[Samueru-sama]

Alright I've been playing with a static podman and distrobox, could not get it to work and it seems podman still needs some other dependencies and several files in /etc for it to work, so an appimage using podman may not be viable.

However I discovered this which is made by main dev of distrobox and if this explanation is right it is just what we need.

However I also can't get lilipod to work. I created two images of ubuntu and alpine and when I try to run them with distrobox or directly with lilipod nothing happens, it just lags for a few seconds and quits.