-
Notifications
You must be signed in to change notification settings - Fork 22
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
Snap/Flatpaks #27
Comments
Or alternatively an AppImage. |
I do not really understand AppImage, is not it just a statically linked binary? Why call it "AppImage" then? |
It contains a (I think mostly readonly) filesystem with all necessary libraries. As far as I remember, the binary is not necessarily static. But I don't remember in detail how it works. |
I am currently using CPack to create Debian .deb files, and even that was a much steeper learning curve than I anticipated. And if someones is willing to maintain them, I am more than happy to pitch in with hosting or the like. |
For appimages it's quite simple if you're doing a qt application. Here's a build script from LibrePCB: https://github.com/LibrePCB/LibrePCB/blob/master/dev/travis/build_appimage.sh It's based on linuxdeployt. It looks like you an also create cross-distro deb and rpm packages with that tool. |
It is a self-mounting filesystem image that can contain whatever you put inside, like a .dmg disk image on the Mac. Usually people put dynamically linked binaries in there, together with all dependencies and resources the application needs that cannot be expected to be part of every target system in a recent enough version. Providing an AppImage would have, among others, these advantages:
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. |
Uhh there is too much optional stuff there in your AppImages. I think AppImages are possibly useful for portable (USB) applications, but for desktop applications I rather want something that auto-updates, obviously has desktop icons and signed updates (important for security reasons!). Having a sandboxed environment is also nice, so far. |
Flatpak is as much Red Hat centric as Snap is Canonical centric imho. AppImage is a different thing, think of it as "PortableApps for Linux". |
It's not, Flatpak is available on much more distros than Snap. AppImage is for portable apps, without an update mechanism and a secure way to deliver those (and first time installs) I cannot consider this for the desktop. |
There is an update mechanism. It's called AppImageUpdate, and it's great because it uses binary deltas (think "diff" but for binaries). AppImages can embed update information (to be used by outside updater tools such as AppImageUpdate) or can even embed the updater, making the AppImage self-updateable (by using
The most secure way imho is to always get the binaries from the original application author, from the same place where the source code resides. In other words, from https://github.com/blizzard4591/openMittsu/releases. |
+1 for a snap By the way: snap and flatpak are available on many distros e.g snap: https://snapcraft.io/docs/installing-snapd |
Just my 50ct: |
@HorstBaerbel in my experience, does not run properly e.g., on most Live ISOs. |
@probonopd Good to know. Not very relevant to openMittsu probably. |
Thanks @HorstBaerbel. Everything has pros and cons. Just to set the record right, there is AppImageUpdate and there is even a Qt plugin that you can bundle with your Qt-based application that will make your application self-updateable... with binary delta updates, which means that only the bits that have actually changed need to be downloaded by the user. |
Providing snaps and/or flatpaks for Linux would be nice and allow you to cover many distros.
The text was updated successfully, but these errors were encountered: