It’s super easy to create. And you distribute it on your own, so it’s basically like an installer exe on Windows. In my mind it’s one step above only offering source code.
I’m curious, what makes AppImage a good choice for the lazy developer? Is it easier to create?
The appimage is basically just git clone -> make -> make install DESTDIR=/path/to/AppDir -> wget appimagecreationtool and finally appimagecreationtool /path/to/AppDir and that’s it you have your appimage.
appimagecreationtool being several tools that can create the appimage from an AppDir, like linuxdeploy, linuxdeploqt, go-appimage, etc
And that on itself isn’t complex either, it if basically running ldd on the binary, then copy those libraries into the AppDir and finally run patchelf to patch the paths in the binaries and libraries, suyu uses a deploy script instead of using those tools, which I’ve recently forked and began expanding.
I don’t know how easy it is to make a flatpak or snap, but I do know the dev of zen browser hates dealing with the flatpak and iirc right now the flatpak is outdated as result.
EDIT: Also lite-xl has been making a flatpak for like 2 years and it isn’t ready yet.
There is no software that is not in AUR. I use arch, BTW.
But yeah, sometimes I just compile from source, if needed.
That’s exactly what the vast majority of AUR packages do already? You can also apply modifications to the compilation process if needed.
My software, QuickDAV, is not in the AUR. It’s open source, and I release it only as an AppImage, because I am lazy.
I guess we should have added the word “notable”
I’m terribly sorry, you left the door wide open ;)
I’m curious, what makes AppImage a good choice for the lazy developer? Is it easier to create?
Ouch. xD
It’s super easy to create. And you distribute it on your own, so it’s basically like an installer exe on Windows. In my mind it’s one step above only offering source code.
The appimage is basically just
git clone->make->make install DESTDIR=/path/to/AppDir->wget appimagecreationtooland finallyappimagecreationtool /path/to/AppDirand that’s it you have your appimage.appimagecreationtool being several tools that can create the appimage from an AppDir, like linuxdeploy, linuxdeploqt, go-appimage, etc
And that on itself isn’t complex either, it if basically running ldd on the binary, then copy those libraries into the AppDir and finally run patchelf to patch the paths in the binaries and libraries, suyu uses a deploy script instead of using those tools, which I’ve recently forked and began expanding.
I don’t know how easy it is to make a flatpak or snap, but I do know the dev of zen browser hates dealing with the flatpak and iirc right now the flatpak is outdated as result.
EDIT: Also lite-xl has been making a flatpak for like 2 years and it isn’t ready yet.
There’s so much random, useful software distributed only as appimages. But not notable enough for packaging fanboys.
Gatekeeping the word “software” here?
Here’s something not in the AUR. Tested on arch
Clearly we need an Arch version of rule 34 and rule 35
Rule 34a: If linux software exists, it’s in the AUR. No exceptions.
Rule 35a: If linux software is not in the AUR, it will be made available in the AUR.
I don’t intend on pushing that one to the AUR. It’s not worth it.
Maybe I’ll make an AppImage at most.
I don’t know any formal requirements for it being on AUR, but I just feel like this one does not fit there.
Sorry, I’ve already posted the new internet rules and they took immediate effect, I’ll have to report this incident to…the council.
Someone will put the AppImage in AUR
This is such a weird gatekeeper take
Its a joke lol, why are you so serious all the time
i use arch based btw (I love my Manjaro and it’s AUR support) :>
https://youtu.be/V1mOWypIFRM