Skip to content
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

Closed
probonopd opened this issue Aug 4, 2019 · 6 comments
Closed

Please provide an AppImage #86

probonopd opened this issue Aug 4, 2019 · 6 comments
Labels
packaging problems or question about the creation/maintenance of packages wontfix This will not be worked on

Comments

@probonopd
Copy link

probonopd commented Aug 4, 2019

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:

  • Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
  • One app = one file = super simple for users: just download one AppImage file, make it executable, and run
  • No unpacking or installation necessary
  • No root needed
  • No system libraries changed
  • Works out of the box, no installation of runtimes needed
  • Optional desktop integration with appimaged
  • Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
  • Can optionally GPG2-sign your AppImages (inside the file)
  • Works on Live ISOs
  • Can use the same AppImages when dual-booting multiple distributions
  • Can be listed in the AppImageHub central directory of available AppImages
  • Can double as a self-extracting compressed archive with the --appimage-extract parameter
  • No repositories needed. Suitable/optimized for air-gapped (offline) machines
  • Decentralized

Here 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.

@probonopd probonopd added the enhancement ideas to improve existing features label Aug 4, 2019
@maoschanz
Copy link
Owner

Possible drawbacks

  • I don't see the point of wasting my time with this.
  • Each app managing its own updates is a dangerous mess.
  • Normal users launch their app from the DE menu, not from the file manager.
  • The normal location for this kind of mess is /opt, but it belongs to root, thus breaking the possibility to have both a clean system AND updates at the same time.

Possible alternatives

Use 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

@maoschanz maoschanz added packaging problems or question about the creation/maintenance of packages wontfix This will not be worked on and removed enhancement ideas to improve existing features labels Aug 4, 2019
@probonopd
Copy link
Author

probonopd commented Aug 4, 2019

I don't see the point of wasting my time with this.

Would you entertain a pull request that would do all the work for you?

Each app managing its own updates is a dangerous mess.

Your opinion, not mine.

Normal users launch their app from the DE menu, not from the file manager.

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)

The normal location for this kind of mess is /opt, but it belongs to root, thus breaking the possibility to have both a clean system AND updates at the same time.

AppImages run from anywhere, including $HOME, $HOME/bin, $HOME/Downloads, removable drives, and network shares. Just from anywhere...!

Use flatpak

This is an option to do in addition, but it is not an alternative because it cannot do what AppImage does.

GNOME apps

I have no GNOME apps on my system.

@maoschanz
Copy link
Owner

Your opinion, not mine.

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)

AppImages run from anywhere, including $HOME, $HOME/bin, $HOME/Downloads, removable drives, and network shares. Just from anywhere...!

I understood you home folder was chaos, now the questions are:

  • do i want to support fragmentation?
  • do i want to support the kind of fragmentation where apps behave like Windows' .exe files?

This is an option to do in addition, but it is not an alternative because it cannot do what AppImage does.

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.

I have no GNOME apps on my system.

Convenient coincidence

Would you entertain a pull request that would do all the work for you?

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

@probonopd
Copy link
Author

AppImage is an option to do in addition, but it is not an alternative because it cannot do what all other packaging systems do.

We can totally agree on this one: The systems are complements, not substitutes.

@probonopd
Copy link
Author

But i would not "compile" or distribute such a package anyway

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.

@maoschanz
Copy link
Owner

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
packaging problems or question about the creation/maintenance of packages wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants