Well. IMO it depends on several factors, but the most important to me are: * Needs to be **reasonably automated**. Maintaining Windows and OSX packages proves to require work, and so we need people actually interested in them enough to keep them up. Unless we have someone that does this, it has to be automated reasonably well to not require manual changes in normal circumstances (like adding data files and the like). * **Not bundling 3rd party binaries**. We are part of what seems to be the odd upstream minority that actually understand distribution's concerns about bundling everything a gazillion times (security, size, effort duplication, take your pick).
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. 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. From the AppImage Wiki I see: > 1. **Gather suitable binaries.** If the application has already been > compiled, you can use existing binaries (for example, contained in .tar.gz, > deb, or rpm archives). Note that the binaries must not be compiled on newer > distributions than the ones you are targeting. In other words, if you are > targeting Ubuntu 9.10, you should not use binaries compiled on Ubuntu 10.04. > For upstream projects, it might be advantageous to compile special builds for > use in AppImages, although this is not required. That sounds reasonable. > 2. **Gather suitable binaries of all dependencies** that are not part of the > base operating systems you are targeting. For example, if you are targeting > Ubuntu, Fedora, and openSUSE, then you need to gather all libraries and other > dependencies that your app requires to run that are not part of Ubuntu, > Fedora, and openSUSE. That too, as it suggests only non-standard deps should be packed (or then it'll depend on them being installed on the target machine). We have very few dependencies, so it's probably OK and we'd have nothing to pack. 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, only support one architecture, or rely on the 32 bit compatibility on 64 bits systems -- but then requires a lot more deps. > 5. **Test your AppImage** on all base operating systems you are targeting. > This is an important step which you should not skip. Subtle differences in > distributions make this a must. While it is possible in most cases to create > AppImages that run on various distributions, this does not come > automatically, but requires careful hand-tuning. That sounds a lot more problematic I guess, because 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: we don't have the manpower nor enough motivation for this I'm afraid. ---- So… well I guess it depends on what AppImage actually is, and on the contributions from interested people. If it's a matter of running a script somewhere, it's probably fine. We could indeed even run it on TravisCI or something if needed. If it however requires some effort upon each release, I'd rather suggest following the OSX approach, that is being maintained by a "3rd party" (well, actually it's a regular contributor aside from that) and us only providing some infrastructure/visibility (repository under the Geany organization, links on the download pages, etc.). And additional concern might be 3rd party plugins, and especially Geany-Plugins. It might be important to have a way to use those from whatever the bundle is, and it might raise some concerns, like should they be part of that bundle, or how to deal with their dependencies (as many have more complex dependencies that Geany). --- 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. That doesn't apply to Geany-Plugins though. -- 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-260629094
