[Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)

[probonopd]

> A quick read on AppImage seems to suggest that it has the good taste of not packing everything in, so that we probably could just distribute actual Geany files in it, so that's good.

We recommend to _bundle everything that cannot be reasonably expected to be part of each target system (default install) in a recent enough version_. This means that if you build on an old enough build system, we can expect something like glibc to "be part of each target system in a recent enough version". However, if you build on a very recent build system, this may not hold true, because your build artifacts will require a too new glibc version which "cannot be reasonably expected to be part of each target system in a recent enough version". So as always, it depends. For practical reasons, I maintain a list of [libraries](https://github.com/probonopd/AppImages/blob/master/excludelist) and [debs](https://github.com/probonopd/AppImages/blob/master/excludedeblist) that I currently assume to "be part of each target system".

> Not sure about how automated it is, but if e.g. it can be created by a script straight out of a make install DESTDIR=somewhere, it sounds easy enough.

There are multiple ways to generate AppImages, among them:

1. **Convert existing binary packages**. This option might be the easiest if you already have up-to-date packages in place, ideally a ppa for trusty or earlier or a debian repository for oldstable. In this case, you can write a small `.yml` file and in many cases are done with the package to AppImage conversion. [See examples](https://github.com/probonopd/AppImages/tree/master/recipes/meta) **OR**
2. **Bundle your Travis CI builds as AppImages**. This option might be the easiest if you already have continuous builds on Travis CI in place. In this case, you can write a small scriptfile and in many cases are done with the AppImage generation. [See examples](https://github.com/search?utf8=%E2%9C%93&q=%22Package+the+binaries+built+on+Travis-CI+as+an+AppImage%22&type=Code&ref=searchresults)

> However, that wouldn't work with 32 and 64 bits out of the box, so the question would be whether the AppImage is supposed to bundle 2 builds

One AppImage per architecture.

> it's unlikely we will really test this fairly continuously. If we were to include this, we'd probably test it fairly at the start, but it's unlikely we'll keep up with this over the next releases

I think it should be OK do do explicit testing with various distros in the beginning and then leave it to people downloading the continuous builds to do the "testing".

> I guess it depends on what AppImage actually is

AppImage is a self-mounting filesystem that simply executes what you put inside. It's up to you what you put inside, but if you follow the general rule to "bundle everything that cannot be reasonably expected to be part of each target system in a recent enough version", then chances are that it will run on many target systems. In practice, building on Travis CI trusty means that the AppImage will run on 2014-ish distributions and later.

> And additional concern might be 3rd party plugins, and especially Geany-Plugins.

Bundle all of them for the optimal out-of-the-box experience.

> BTW, note that Geany is supposed to have binary relocation support (event though virtually nobody tests it), so theoretically one could simply build Geany with that enabled, and distribute a simple tarball.

If you put the contents of this tarball inside an AppImage, then you gain the additional advantage that your users won't have to unpack a tarball, but can just run the image.

> Gathering dependency versions over a number of distributions is possibly a problem, think the recent libvte debacle where some distros shipped 2.90, some 2.91 and some something else. Automating that is gonna be difficult. And various plugins and webkit versions. And gtk2 or 3? And so on.

In practice this is actually easy, run ldd on your app and bundle what it returns. Then delete libraries that we can reasonably expect to be part of each target system in a recent enough version from the bundle.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/1303#issuecomment-260708727
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20161115/d268abb0/attachment.html>