<blockquote>
<p>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.</p>
</blockquote>

<p>We recommend to <em>bundle everything that cannot be reasonably expected to be part of each target system (default install) in a recent enough version</em>. 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 <a href="https://github.com/probonopd/AppImages/blob/master/excludelist">libraries</a> and <a href="https://github.com/probonopd/AppImages/blob/master/excludedeblist">debs</a> that I currently assume to "be part of each target system".</p>

<blockquote>
<p>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.</p>
</blockquote>

<p>There are multiple ways to generate AppImages, among them:</p>

<ol>
<li>
<strong>Convert existing binary packages</strong>. 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 <code>.yml</code> file and in many cases are done with the package to AppImage conversion. <a href="https://github.com/probonopd/AppImages/tree/master/recipes/meta">See examples</a> <strong>OR</strong>
</li>
<li>
<strong>Bundle your Travis CI builds as AppImages</strong>. 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. <a href="https://github.com/search?utf8=%E2%9C%93&q=%22Package+the+binaries+built+on+Travis-CI+as+an+AppImage%22&type=Code&ref=searchresults">See examples</a>
</li>
</ol>

<blockquote>
<p>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</p>
</blockquote>

<p>One AppImage per architecture.</p>

<blockquote>
<p>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</p>
</blockquote>

<p>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".</p>

<blockquote>
<p>I guess it depends on what AppImage actually is</p>
</blockquote>

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

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

<p>Bundle all of them for the optimal out-of-the-box experience.</p>

<blockquote>
<p>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.</p>
</blockquote>

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

<blockquote>
<p>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.</p>
</blockquote>

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

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/geany/geany/issues/1303#issuecomment-260708727">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABDrJ0tZtFjy5VMrOJyjKjNGdutnSYoaks5q-ev7gaJpZM4KyPT8">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ABDrJxDSpmTM4SkfT6RsPsS3LUn0X4uCks5q-ev7gaJpZM4KyPT8.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/geany/geany/issues/1303#issuecomment-260708727"></link>
  <meta itemprop="name" content="View Issue"></meta>
</div>
<meta itemprop="description" content="View this Issue on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/geany/geany","title":"geany/geany","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/geany/geany"}},"updates":{"snippets":[{"icon":"PERSON","message":"@probonopd in #1303: \u003e 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.\r\n\r\nWe 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\".\r\n\r\n\u003e 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.\r\n\r\nThere are multiple ways to generate AppImages, among them:\r\n\r\n1. **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**\r\n2. **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\u0026q=%22Package+the+binaries+built+on+Travis-CI+as+an+AppImage%22\u0026type=Code\u0026ref=searchresults)\r\n\r\n\u003e 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\r\n\r\nOne AppImage per architecture.\r\n\r\n\u003e 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\r\n\r\nI 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\".\r\n\r\n\u003e I guess it depends on what AppImage actually is\r\n\r\nAppImage 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.\r\n\r\n\u003e And additional concern might be 3rd party plugins, and especially Geany-Plugins.\r\n\r\nBundle all of them for the optimal out-of-the-box experience.\r\n\r\n\u003e 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.\r\n\r\nIf 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.\r\n\r\n\u003e 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.\r\n\r\nIn 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."}],"action":{"name":"View Issue","url":"https://github.com/geany/geany/issues/1303#issuecomment-260708727"}}}</script>