Closed icavalheiro closed 3 years ago
Providing an AppImage would have, among others, these advantages:
appimaged
--appimage-extract
parameterHere is an overview of projects that are already distributing upstream-provided, official AppImages.
Providing an AppImage would have, among others, these advantages
Considering who the author of the software happens to be as well as their prominence within the snapcraft community you're engaging in an act of utter futility. This isn't going to happen. The code is there, though, to allow you to package it in those formats on your own if you are so inclined.
The original poster requested Flatpak or AppImage. You say the author does Snap. So why not have all three? It's really not an either-or...
It's not an either or. But it is a question of how much one individual developer is willing and able to support. You say "all three", but there are more packaging systems out there. Why should rpm not be counted?
Long story short, if you want to get uptake in another format than the developer provides you need to find someone who is willing to take on supporting it. As the source is freely available that makes it a lot easier.
The original poster requested Flatpak or AppImage. You say the author does Snap. So why not have all three? It's really not an either-or...
The problem there is that you are making a tremendous assumption as to your entitlement. You are owed nothing. The author could have just as easily thrown the code over the wall without packaging. That a choice was made to use just snaps reflects a choice of how to direct time and resources.
It is far less intensive for potential users to just install snapd according to the directions for their distribution.
Hi, can you consider publishing this package to Flathub or adding AppImage support? Snaps are great but not all systems come with it preinstalled (specially pop_os and elementary).