bread VS go-appimage

NOTE: I don't know when and if to add new AppImages from the main catalog, also because a part of them is mostly broken and out of control. The AppImage packages compiled and managed by "AM"/AppMan are new AppImages that use scripts that also allow constant updating and recompilation from scratch, as if they were installed from AUR, using more reliable sources (official repositories for Debian and derivatives) . If you are interested more to the applications made available officially from the official AppImage.GitHub.io catalog, I suggest you to use Zap, Bread or the aforementioned Appimagedl. All these amazing utilities can be quickly installed via "AM" or AppMan.

The preferred sources for downloading packages in AppImage format via "AM" / AppMan are GitHub and Sourceforge, however, writing installation scripts that are compatible with one or more programs is a difficult task. Just think that many developers add multiple versions of the same product in the same tag (I have to include also commands to find the exact name of the latest version to avoid the download of other packages), or include more complex links that require an equally complex function to obtain the latest version of a program, and this slows down the loading of these programs on the "AM" repository I manage. I have therefore included excellent AppImage package managers such as "Bread" and "Zap" among the downloadable programs, but also "AppimagePool" and "bauh" are available among the graphics applications (not counting a "Pacstall" AppImage versionI made). These tools should compensate the lack of support for certain sources that I have not included in the "AM" repository.

My project bread or AppMan by Ivan are basically package managers for AppImages, I use GitHub release & the Above given appimage.github.io API to get the information related to AppImages stored in this repository, and AppMan has it's own repository maintained by Ivan.

Bread 🍞: https://github.com/DEVLOPRR/bread

Snap and flatpak run a daemon to integrate into your system. Appimage has an optional daemon to give you the same integration https://github.com/probonopd/go-appimage

Handles making it executable, automatic upgrades, no need to move it to your $PATH, and adds the application to your app list.

Only other thing you might want to do is symlink a friendly name for cli

It's possible to make appimages that bundle a libc, although most don't. The go-appimage project contains a static build tool that will bundle the linker and wrap executable invocation in that. The intention seems to be providing support on older systems for programs built with a glibc that is too new, but I'm using it to ship a musl binary that can run on glibc systems.

I look forward to watching the FOSDEM talk this weekend, so perhaps getting ahead of myself. But I'm curious whether you think the move in appimage toward static linking would solve some of the hairy issues you pointed out? For example: https://github.com/AppImage/AppImageKit/issues/1193 and https://github.com/probonopd/go-appimage/

AppImage This seems like a convenient way of keeping Wine isolated from rest of the system. However, the documentation is still in research phase for this: https://github.com/AppImage/AppImageKit/wiki/Bundling-Windows-applications https://github.com/probonopd/go-appimage https://github.com/TheAssassin/AppImageLauncher https://github.com/sudo-give-me-coffee/wine32-deploy

There's an automatic way to make .desktop entries from appimage, I use https://github.com/probonopd/go-appimage/blob/master/src/appimaged/README.md

There are helper programs to help you manage them and integrate them with the system like other package formats.

their is you can use appimaged https://github.com/probonopd/go-appimage

Would be great if most distros (including Ubuntu, Fedora, etc.) would include AppImageLauncher or appimaged by default. Would make it much simpler for most people.