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

<p>Yes, I'm well aware about binary compatibility.</p>

<blockquote>
<p>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>I see you list GTK+2 as a base library, so the bundle shouldn't require much libraries.</p>

<blockquote>
<p>These lists are not perfect, however, so if you think that <code>libpangoft2-1.0.so.0</code> should be added, you may well be right.</p>
</blockquote>

<p>PangoFT is a GTK2 dependency, so there's no reason to bundle it more.  We don't depend on it directly either, only through GTK.</p>

<blockquote>
<p>Effectively, it is exactly what you'd do if you target the macOS or Windows platforms.</p>
</blockquote>

<p>Unfortunately those are terribly painful, so it's not really a selling point :)</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, […]</p>
</blockquote>

<p>Well, actually it seems far less "magical" than I hoped for, and a lot more like a mere unpack-and-run type of thing.  For example, the need to patch everything under the installation directory to create relative installation directories.  BTW, about that:</p>

<ul>
<li>running <code>sed</code> on binary files requires care.  Basically, you need to make sure that <code>LANG=C</code> (IIRC), otherwise it might not work and/or mess up the result.</li>
<li>running <code>sed</code> is hacky, but also might catch inappropriate things, in the string <em>/usr</em> ever happens in something else than a path to a bundled data file/library.</li>
</ul>

<p>I somewhat had the crazy hope there was a way to somehow overlay a filesystem over <code>/</code> for the context of an app, and so that it would really be transparent.</p>

<hr>

<p>Anyway, it doesn't change much yet.  At least for setting it up initially, we probably would need someone motivated -- and sorry, knowing exactly what he/she's doing.  I'm not dismissing any effort here, and I definitely know that many things come with trial and error, I'm just saying that it'll likely take more time to end up with a "good" result.</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-260731250">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABDrJ-zXmWnFCvPD14mIonHZ5og8wCI7ks5q-f9LgaJpZM4KyPT8">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ABDrJ3y8-S7R0H1KaIamJSerGW9qUt6xks5q-f9LgaJpZM4KyPT8.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-260731250"></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":"@b4n in #1303: \u003e 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.\r\n\r\nYes, I'm well aware about binary compatibility.\r\n\r\n\u003e 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\nI see you list GTK+2 as a base library, so the bundle shouldn't require much libraries.\r\n\r\n\u003e These lists are not perfect, however, so if you think that `libpangoft2-1.0.so.0` should be added, you may well be right.\r\n\r\nPangoFT is a GTK2 dependency, so there's no reason to bundle it more.  We don't depend on it directly either, only through GTK.\r\n\r\n\u003e Effectively, it is exactly what you'd do if you target the macOS or Windows platforms.\r\n\r\nUnfortunately those are terribly painful, so it's not really a selling point :)\r\n\r\n\u003e AppImage is a self-mounting filesystem that simply executes what you put inside. It's up to you what you put inside, […]\r\n\r\nWell, actually it seems far less \"magical\" than I hoped for, and a lot more like a mere unpack-and-run type of thing.  For example, the need to patch everything under the installation directory to create relative installation directories.  BTW, about that:\r\n* running `sed` on binary files requires care.  Basically, you need to make sure that `LANG=C` (IIRC), otherwise it might not work and/or mess up the result.\r\n* running `sed` is hacky, but also might catch inappropriate things, in the string */usr* ever happens in something else than a path to a bundled data file/library.\r\n\r\nI somewhat had the crazy hope there was a way to somehow overlay a filesystem over `/` for the context of an app, and so that it would really be transparent.\r\n\r\n---\r\n\r\nAnyway, it doesn't change much yet.  At least for setting it up initially, we probably would need someone motivated -- and sorry, knowing exactly what he/she's doing.  I'm not dismissing any effort here, and I definitely know that many things come with trial and error, I'm just saying that it'll likely take more time to end up with a \"good\" result."}],"action":{"name":"View Issue","url":"https://github.com/geany/geany/issues/1303#issuecomment-260731250"}}}</script>