-
-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please provide an AppImage #86
Comments
Possible drawbacks
Possible alternativesUse flatpak to run it on many distributions with no system librairies changed and a perfect system integration. It's decentralized too, and the runtime is the same as all other GNOME apps so it should already be here. So it's a no. But you can package it as an appimage yourself if you want, i let the issue open if you have questions regarding the dependencies |
Would you entertain a pull request that would do all the work for you?
Your opinion, not mine.
The optional appimaged daemon or thrid-party solutions like AppImageLauncher can put it in the menu automatically. (Side note, the Freedesktop XDG stuff lacks behind what the Mac and Haiku offer, so it's really a crude workaround)
AppImages run from anywhere, including $HOME, $HOME/bin, $HOME/Downloads, removable drives, and network shares. Just from anywhere...!
This is an option to do in addition, but it is not an alternative because it cannot do what AppImage does.
I have no GNOME apps on my system. |
My opinion is the opinion of the guy who will have to deal with issues from obsolete versions of his app for years because with appimages, every component providing basic package management features is optional (= less than 1% of users have it)
I understood you home folder was chaos, now the questions are:
I correct your typo: AppImage is an option to do in addition, but it is not an alternative because it cannot do what all other packaging systems do.
Convenient coincidence
It depends on the pull request content, if it's just one or two script ok. But i would not "compile" or distribute such a package anyway |
We can totally agree on this one: The systems are complements, not substitutes. |
Well, the whole point of AppImage is that the application author (you) can provide and support a downloadable executable and control the whole experience of it ("upstream packaging"). Looks like you are not interested in that. |
Yes, sorry but my upstream package already exists, it's the flatpak one, which is use. Then, the rest (Ubuntu PPA, Fedora main repo, Arch Community repo, etc.) is managed by people using these package formats themselves. It would be weird to do an exception for a package format that i don't even consider as a valid way to provide an app... |
Problem
I cannot easily download and run Drawing like I can e.g., Krita.
Suggested solution
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.
If you have questions, AppImage developers are on #AppImage on irc.freenode.net.
Possible drawbacks
None.
Possible alternatives
None that match the feature set described above.
The text was updated successfully, but these errors were encountered: