search

jordansissel / fpm

Effing package management! Build packages for multiple platforms (deb, rpm, etc) with great ease and sanity.
http://fpm.readthedocs.io/en/latest/
Other
11.14k stars 1.07k forks source link

Support AppImage format for Linux #1133

Open probonopd opened 8 years ago

probonopd commented 8 years ago

AppImage is a format for portable, distribution-agnostic binary software deployment for Linux without needing root permissions or installation. (Wikipedia)

Here are some sample applications in AppImage format: https://bintray.com/probono/AppImages/

And here are the scripts which produced them: https://github.com/probonopd/AppImages

It would be nice if AppImage generation could be automated in fpm. I am happy to help if there is interest.

probonopd commented 8 years ago

This might serve as the starting point for a deb2appimage script: https://github.com/probonopd/AppImages/blob/master/recipes/meta/Recipe

@jordansissel let me know if there is interest for me to genericize and comment it.

hatt commented 8 years ago

After a look at the format specification, it seems very architecture-portable but not platform-portable. We can currently build OSX PKG files but not DMG files for almost this exact reason. The documentation specifies that the AppRunner can be either shell or C but C is recommended, are the runners for various apps generally simple enough to be crosscompile-able from say OSX to Fedora? I don't think anyone expects to build on one OS for another so that's probably not a big deal but AppImage definitely seems like the most limited of recent package formats for Linux due to this.

Another thing is the use of ISO9660. Looks like Ruby has very little maintained gems for handling this, especially the zisofs compression scheme, which would be needed to build AppImage packages natively. We'd probably need to shell out to existing tools, and given the setup requirements of AppImage I'm not sure how FPM wouldn't just make the packaging process even more complicated that way.

probonopd commented 8 years ago

After a look at the format specification, it seems very architecture-portable but not platform-portable

Not sure I understand what you mean with this, please elaborate. AppImage targets Linux distributions. BSD could possibly follow but we haven't investigated it yet. AppImages can be generated on other systems like macOS too if you have binaries of the Linux application to be packaged available (ideally in deb form).

The documentation specifies that the AppRunner can be either shell or C

For all practicality, just use the precompiled AppRun. That is what the script linked above does.

are the runners for various apps generally simple enough to be crosscompile-able from say OSX to Fedora

The same AppRun can be used for 99% of all AppImages out-of-the-box, so there is nothing to compile, just copy the existing one into the AppDir.

I don't think anyone expects to build on one OS for another

The main question is how would a macOS user build a Linux app (not talking about AppImage here but about the payload app). electron-builder can do it for Electron apps, and it can package as an AppImage for Linux on a macOS build host.

AppImage definitely seems like the most limited of recent package formats for Linux due to this

Please elaborate, I do not understand this statement. AppImage may well be the most lightweight of the different bundling solutions, and possibly the most powerful for that exact reason.

ISO9660. Looks like Ruby has very little maintained gems for handling this (...) We'd probably need to shell out to existing tools

Would that be an issue? If you look at the electron-builder implementation, the only external tool they use is xorriso. The actual packaging is a relatively simple JavaScript in their case. (In the Electron case, generation of the AppDir is relatively simple though.)

I'm not sure how FPM wouldn't just make the packaging process even more complicated that way

It would allow people who know little about AppImage to produce AppImages with relative ease. And it should be doable given that FPM already can produce deb files which could serve as the input to the AppImage generation.

develar commented 8 years ago

electron-builder uses FPM to build all other Linux targets. And actually, FPM is more powerful tool to build than AppImage builder because file mappings are supported. But anyway — AppImage format is very simple, so, you can just use xorriso and nothing else.

It is why I decided to not fix FPM to support AppImage, but instead generate it using xorriso directly.

mthbrown commented 1 year ago

It would be great to add this