bauh VS go-appimage

Like bauh which supports AppImage, Arch packages (including AUR), Debian packages, Flatpak, Snap and native Web applications

github/vinifmor/bauh

If you really want a GUI package manager that doesn't break EndeavourOS, I've had a good experience with bauh when I started using EOS. But I also do everything with yay now, as others have suggested, it is more convenient once you know the commands.

Lastly, deb-get + pacstall + bauh. All of these combined covers 99% of my software needs, much less need to find and install PPAs and .deb manually. Still not as convenient as AUR, but much better than it was before. Hopefully, eventually everything is on Flatpak, snap, or AppImage so I could just use Bauh for most apps, but for now, I'm glad that these tools exists.

Is it an AppImage? Did you make it executable? If you use a lot of AppImages then you may want to add DE integration via their utility. I do not use it, as it runs a backgroudn daemon, I prefer using bauh instead.

Bauh https://github.com/vinifmor/bauh

You can use bauh. Supports AppImage, Arch packages (including AUR), Debian packages, Flatpak, Snap and native Web applications. GitHub

You may wanna take a look at bauh.

Although, if I had to I would personally suggest bauh if you want a graphical package manager. I haven't had any issues with using it, and neither have I seen people complaining about it. It also supports the following formats: AUR packages, AppImages, Flatpak, Snap and Web applications. It also integrates with Timeshift to provide a simple and safe backup process before applying changes to your system.

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.