Feature request: Please provide an AppImage for Geany

[fusion809]

Hi,

At the moment Linux users are essentially left to wait until their respective distribution's repositories are updated and the new release of Geany is added. This process is so tedious, however, that for most non-bleeding edge distributions one has to wait months or years for this to happen (by which time usually an even newer release of Geany is out). So what I propose is that you's provide your own AppImages for Geany. AppImages, for those of you that are unaware, are a type of cross-distribution packaging format that need no special tools (like no special package manager to manage the packages) in order to be run. They merely need to be marked executable (with chmod +x) and run (with ./<AppImage> where <AppImage> is the AppImage's filename, including its file extension). They are essentially self-mounting image files with an internal file system that contains all the files required to run the program they provide (which in this case would be Geany, of course).

I have created my own AppImage for Geany (which you can find here) but as you might notice it is presently out of date (version 1.28, versus the latest release of 1.29) as the Debian packages (and no this does not mean that this AppImage will only run on Debian systems, it will run on Arch Linux, Fedora, Gentoo, openSUSE, etc. as well) I built it from are presently out-of-date (although no doubt they will be updated soon). Plus my AppImage is built using Debian (Jessie) ingredients so it doesn't work on systems older than Jessie, while it is possible that you's could create a more flexible AppImage. You's could use your Travis CI artefacts instead of the Debian packages I use to build the AppImage, hence providing the very latest (more up-to-date than I could ever hope to provide) build of Geany. The way I uploaded my Geany AppImage to Bintray was using Travis CI, so they both easily integrated with one another. Alternatively you could upload the AppImages to the releases page of this GitHub repository.

If you need help with this I am more than willing to help, although I do believe @probonopd will be far more helpful than I, due to his superior knowledge of AppImages (after all he is the one that created the AppImage format).

Thanks for your time,
Brenton

[elextr]

In general the Geany project has decided it will NOT provide packages itself for anything other than windows (and that only just). The Geany developers are not experts in any packaging system, and to become so, and to provide such packages would detract from the effort available for Geany development. Instead a wonderful set of contributors who are experts in packaging provide the packages for various systems.

If somebody wishes to provide so called portable packages, appimages, flatpacks, snaps or whatever and host them (eg on github), and most importantly MAINTAIN them, they are most welcome to, and Geany is happy to provide a link to them. But it is unlikely that the project itself will start providing such packages.

[fusion809]

OK, although I just looked at your .travis.yml file and as it builds your source code on Ubuntu already I suspect it might be possible to turn that into an AppImage with minimal effort. @probonopd what do you think? If probonopd could explain how to do this to me I'd be willing to take care of this for yas. Like through a pull request. I'd love to eliminate the need of effort on the part of the Geany development team in order to get this done.

[probonopd]

@fusion809 I am happy to support upstream projects that are willing to do upstream packaging, to provide a polished end-to-end user experience. But it doesn't seem to be the case that this project is willing to produce binaries for Linux.

[fusion809]

'tis a shame. I've spent the past few hours trying to set up a Geany package in the Open Build Service for CentOS 5 and 6. That way I could use these packages to build a more up-to-date yet with older ingredients AppImage. Sadly that's failed pretty miserably. Now I'm gonna try Debian, but knowing how much more challenging Debian packaging is for me I suspect it won't be as successful as I am hoping for.

[b4n]

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.

1. 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.

1. 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.

[elextr]

@b4n, don't forget geany-plugins too, with its greater dependency requirements.

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.

[fusion809]

Well my efforts to create a Debian package for 1.29 of geany and geany-plugins has failed, with the geany-plugins package's build failing. Geany was fairly easy to build. I moved to Launchpad, instead of using the Open Build Service. The geany-plugins package's build failed with the error shown in this build log. I've spent around 5 hours trying to build a suitable Geany and Geany Plugins 1.29 package to build an AppImage from and it truly is a pain. Then again, the only Linux package format I'm really adept at building are Arch Linux (i.e., pacman) packages. Why can't all package source files be as easy to write as PKGBUILDs... I suspect building these packages would be far easier for you Geany developers though, as you know how to get rid of build errors better than I.

[b4n]

It failed with the error shown in this build log.

The error is pretty straightforward: GitChangebar plugin is force-enabled (--enable-gitchangebar), but one of its dependencies is missing:

Requested 'libgit2 >= 0.21' but version of libgit2 is 0.19.0

Either don't build this plugin, or use a recent enough version of libgit2.

[frlan]

Wondering why to invent the basics again: There is a src-rpm available for Fedora to fit needs to RH as well as there are deb for Debian could be used as basic.

[fusion809]

@frlan Yeah the Debian package has much of its source files borrowed from another PPA. I tried to create RPMs for CentOS using existing spec files that I had modified to get them to work. I haven't been trying to re-invent the wheel. @b4n Fair enough, thanks, had such a long log I couldn't read it all, I searched for "error:" to try and narrow it down to the meat of it, but there were like 120 matches for that so... Building it on Xenial (with libgit2 0.24) also fails. One mo I'll that error too.

[fusion809]

Disabling the gitchangebar plugin I get this error https://launchpadlibrarian.net/293530996/buildlog_ubuntu-trusty-amd64.geany-plugins_1.29-3~trusty_BUILDING.txt.gz.

[b4n]

Hum that's odd…

config.status: error: cannot find input file: `po/Makefile.in.in'

Normally this file should be copied over by glib-gettextize I think. I see 2 possible reasons:

• We depend on something newer than what you have, but don't advertize it (I doubt it, because AFAIK we didn't touch this area since 2010 or so)
• The Debian package doesn't call our autogen script and doesn't call glib-gettextize, nor any other tool that would crate this file (autopoint, intltool or gettextize maybe), possibly because newer versions of some tool (autoreconf or dh_autoreconf) do that automatically now.

A quick and dirty solution could be calling our autogen script, not sure (beware that AFAIK dh_autoreconf does extra magic). Or calling the appropriate tool explicitly.

[b4n]

BTW, I see:

configure: WARNING: unrecognized options: --disable-maintainer-mode, --enable-geanylipsum, --enable-geanysendmail

GeanyLipsum and GeanySendMail have been renamed without the Geany prefix.

--disable-maintainer-mode I'm not sure, maybe it requires a newer Automake or something. Not sure if it has any relevance though.

[fusion809]

@b4n thanks for the help. I simply don't understand Debian rules files enough switch to using the autogen script. That's where PKGBUILDs are so much better, with it there's no special macros or commands (like dh_autoreconf) just the standard set of commands one has access to at the command-line. I was hoping that this process would be as simple as copying existing Debian source files and modifying them slightly (like change config options like you mentioned in your last comment).

EDIT: Although I found a line in another rules file for Geany that might work... I think it redefines the dh_autoreconf function.

[fusion809]

My latest effort failed https://launchpad.net/~brentonhorne/+archive/ubuntu/geany2/+build/11204415. I just tried to fix this by removing the install file for git-change (forgot to do that after disabling it).

[b4n]

Well, the po/Makefile.in.in part is gone. Would be better to know why it was there, and how it was fixed, but well.

Now it seems there's still reference to git-changebar plugin:

dh_install --list-missing -Xusr/share/doc/geany-plugins/ -X.la
cp: cannot stat ‘debian/tmp/usr/share/geany-plugins/git-changebar’: No such file or directory
dh_install: cp -a debian/tmp/usr/share/geany-plugins/git-changebar debian/geany-plugin-git-changebar//usr/share/geany-plugins/ returned exit code 1

[fusion809]

Now I'm getting https://launchpadlibrarian.net/293539813/buildlog_ubuntu-trusty-amd64.geany-plugins_1.29-5~trusty_BUILDING.txt.gz. I changed the --enable-geanylipsum part of my rules file to --enable-lipsum. But it seems like this plugin is being installed to a different location to where it was when this rules file was last edited by its original writer.

[b4n]

Yes, they have been renamed as I said, and their files too (like the DSO)

dh_install: geany-plugin-lipsum missing files (/usr/lib/*/geany/geanylipsum.so), aborting

[fusion809]

Well I'll be ...... it built correctly! Might have taken 8 hours of work but I finally Debian packages for geany and geany-plugins building for Trusty! @b4n Thanks for your help!

[fusion809]

Oh happy day, I just created an AppImage from these Debian packages of mine. It seems to be working, but I'm gonna perform some more tests before I'll be able to say for certain.

[fusion809]

Just published the AppImage with Travis CI on Bintray, so if anyone wants to try it out feel free https://bintray.com/fusion809/AppImages/Geany/1.29.glibc2.17.

[fusion809]

@probonopd On my Ubuntu 16.10 VM I get this error:

/bin/bash: ../lib/x86_64-linux-gnu/libtinfo.so.5: no version information available (required by /bin/bash)

(geany:4134): Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap",
/tmp/.mount_4Ad7s6/usr/bin/geany: symbol lookup error: /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0: undefined symbol: hb_buffer_set_cluster_level

which is odd. My Debian (Jessie)-based Geany AppImage gave the same error when it didn't contain libpangoft2 files but this AppImage includes a file /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0. Any ideas? Please tell me I won't have to resort to using strace?

[b4n]

Yeah, don't bundle all the libs, just Geany itself.

[eht16]

While I see certain advantages of approaches of AppImage (or Snappy or Flatpack or ZeroInstall or whatever), I have two remarks:

• here is the wrong place to talk about, we provide the software, not the deployment
• your initial argumentation seems wrong to me: you say because your distribution is slow(in your recognition) on package updates, you tell us to do your distribution's job.
  If your distribution is too slow or conservative on package updates for you, then either you should think about changing the distribution or talk to the package maintainer of Geany of your distribution.
  Again, we provide software, not deployment. At least not for non-Windows and non-MacOSX systems where just nothing like package managers and package maintainers exist, unfortunately.

Anyway, back to topic, I agree with @b4n: if there is someone (like you) who is willing to provide constantly properly built and tested AppImages for Geany, that would be a nice addition for all users.

[fusion809]

Yeah, don't bundle all the libs, just Geany itself.

AppImages are designed to work out-of-the-box, without one needing to install any extra libs. libpangoft2 isn't a core lib to my understanding, so we can't just assume it will be provided by most Linux distributions.

[fusion809]

@eht16 Not my distribution, all distributions that are not bleeding-edge take a while to update their Geany package. Even unofficial repositories that provide more up-to-date builds of Geany for most distros tend to lag behind. See for example the geany-dev/ppa (which is mentioned on the Third Party Packages page https://www.geany.org/Download/ThirdPartyPackages#ubuntu) for Ubuntu it still provides 1.27.

[b4n]

libpangoft2 isn't a core lib to my understanding, so we can't just assume it will be provided by most Linux distributions.

IMO it can be considered to be. I'm not aware of any common distributions that don't come up packed with all GTK libraries, which depends on Pango, Cairo and whatnot. IMO, Geany itself has no non-"core" hard dependencies, the only open that might not be is libvte on GTK2, but it's runtime-optional.

Plugins are a different story.

[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 and debs that I currently assume to "be part of each target system". These lists are not perfect, however, so if you think that libpangoft2-1.0.so.0 should be added, you may well be right.

Effectively, it is exactly what you'd do if you target the macOS or Windows platforms.

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 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

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.

[b4n]

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.

Yes, I'm well aware about binary compatibility.

For practical reasons, I maintain a list of libraries and debs that I currently assume to "be part of each target system".

I see you list GTK+2 as a base library, so the bundle shouldn't require much libraries.

These lists are not perfect, however, so if you think that libpangoft2-1.0.so.0 should be added, you may well be right.

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.

Effectively, it is exactly what you'd do if you target the macOS or Windows platforms.

Unfortunately those are terribly painful, so it's not really a selling point :)

AppImage is a self-mounting filesystem that simply executes what you put inside. It's up to you what you put inside, […]

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:

• 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.
• 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.

I 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.

---

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.

[b4n]

And so that there's no misunderstanding:

• We do appreciate 3rd party packages, we thank people working on those.

• But I will not support a Linux binary package bundling all dependencies myself. We would of course add a link to the website and such if someone asks us to do so for such a 3rd party package, but I will not want much part in the package itself.

• Ultimately, we see ourselves as the upstream of the Geany source code as @eht16 said.

  • If we make Windows installers ourselves, it's because we know Windows users are unlikely to build the source code, and that there is no one else to do it for us. Believe me that Windows support altogether is a constant headache -- well, we manage pretty well at forgetting about it though :)

  • OSX packages are an initiative of one of our contributors. We are very glad he did that, but it still is a 3rd party package for which we simply provide some infrastructure, like hosting.

    By 3rd party here I mean that it's the work of someone, but not "the Geany project": he committed to do that package, but we didn't. We sure hope he'll keep doing it, and if he doesn't that someone interested will take over his work, but that package is not part of our "schedule".

  There are several reasons for that, and the more prominent are I guess manpower (we're a very small team), and personal motivation (someone would have to do it, and being volunteers we generally prefer to do things we like here :).

All that to say that we'll provide technical support to whoever want to create packages, and be happy to see someone motivated. But we're unlikely to spend much effort doing the work itself at this time.

[brunob]

Sure, i was just posting for the record :p

[probonopd]

Just wanted to say that I really like the constructive collaboration here. Thank you @fusion809 and everyone and keep up the good work!

[ecmu]

Thanks to @probonopd I created an AppImage for geany including geany-plugins using Travis-CI.
Releases and source code can be found here:
https://github.com/ecmu/geany.AppImage/releases

Maybe these AppImages could be included directly into Geany releases ?

[probonopd]

Thanks @ecmu, your AppImage is running well for me. 👍 It's great to be able to just download one file and run the latest Geany, no matter the distribution.

@b4n @eht16 @codebrainz would you be open to a pull request that would automatically build and upload an AppImage using Travis CI? That would make it easy for people to find. Also, it is generally recommended to download AppImages only from trusted original application authors rather than third-parties. Hence, having an official AppImage (like an official exe and dmg) would be highly appreciated.

I am happy to help if you have additional requirements.

Thanks for your consideration.

[elextr]

@probonopd remember this comment and this comment are you going to maintain it?

If so then similar to the OSX support possibly we could provide a geany/appimage repository that you could use and, as said before, link to it from the website as we do for OSX.

If not then please find someone else willing and capable of doing it, please stop trying to push the workload on to people who have already said they are not willing or able to do it.

[probonopd]

Hi @elextr. @ecmu has done the work, and I am willing to work with the Geany project to bring it into the official Geany pipelines. Once it is there, it needs next to no continous maintenance, but if something breaks I will be there to fix it.

What I don't want to do is do "third-party packages". I am willing to help the Geany project make official ones.

[elextr]

What I don't want to do is do "third-party packages". I am willing to help the Geany project make official ones.

Well, if its in a repository inside the Geany organisation like the OSX packaging is, that should be official enough.

But as has been said before, the "Geany project" itself does not want to make distributions or include distribution support inside the main repository. Or rather, as the "Geany project" is a collection of volunteers, not a corporate supported entity with paid contributors, the volunteers have declined to use their own spare time for this purpose.

And that applies to the Geany plugins collection as well.

Whilst the Geany team has declined to volunteer to support making a distribution themselves, they have not said it should not be done and do not want to prevent it being done, as you can see from the level of assistance provided above to someone who did do it.

Using a repository separate from both Geany and Geany-plugins would put the package in the same place for convenience. The maintainer of the package can be allowed to commit to that repository as the OSX maintainer does to the OSX repository, without having to make pull requests on the main repository. Pull requests on the main repository need contributors with commit rights to review and test it, and most of them have already stated that they are not interested in doing so for distribution packaging related things.

By the way, that the windows packaging material is in the main repositories is purely historical, it might be nice to separate it too, but nobody has the time to spare to do that, so it will stay for now. But the originator of the windows packaging continues to support it.

[probonopd]

Thanks for your detailed explanation @elextr. I would have no issues with it being in a separate repository; the only question is how can the separate repository be triggered to build when a git push happens to the main repository.

[elextr]

Are you really sure you want to do it every push? I'm not sure its good to inflict in-development stuff on users. Although we try to keep everything in master working, its not always the case, for example for some time prior to the 1.35 release several languages symbols didn't work, and the merge that fixed them broke several others which were only just fixed before release

Perhaps its better to only build packages on releases.

IIUC the OSX packages are manually triggered (but I'm not really sure, @techee should correct me if needed) and of course nothing for windows is built in Travis.

[probonopd]

packages are manually triggered

That's the kind of manual work I want to avoid.

Are you really sure you want to do it every push?

It's great for testing, yes. In fact, doing it right in the main repo would even do it for every pull request (but obviously put the download link URL only in the build log of that PR), which imho is an even greater advantage.

[kugel-]

@elextr @probonopd I would welcome if somebody steps up to provide an AppImage (based on releases) under the Geany umbrella.

[ecmu]

@kugel-: Well, I already do that in my repository : https://github.com/ecmu/geany.AppImage
So I volunteer!

What do you think about my work?
I am quite new in github, so tell me what to do if you want it as Geany repository...

[andy5995]

An AppImage would be cool, @ecmu I starred your repo. :) Other people should too ;)

[DwarfFighterCleric]

@kugel-: Well, I already do that in my repository : https://github.com/ecmu/geany.AppImage

Dude! YOU ROCK! Thank you so much!
Your efforts are not in vain
AppImage is such a great format, I wish it got more attention

[andy5995]

I see @ecmu just released an updated Appimage for Geany 1.38.0

Seems like it shouldn't be too difficult to merge that repo setup with Geany's official repo, so the AppImage would be more visible and available, etc. @eht16 @b4n

[kugel-]

I pondered over creating a flatpak for Geany. I'm not sure about the pros and cons of AppImage vs flatpak, though. What would be better, or can you usefully have both?

[probonopd]

I'd encourage you to have both. The two formats are for completely different use cases. Here is a comparison.

[eht16]

We also have #2926 now. Where to continue the discussion?
Until decided, I will add my remarks here.

For me, #1303 (comment) and #1303 (comment) are still valid (even five years later).

We already have more to do than we are able manage and putting even more work on us won't improve the situation.
I still think we (the Geany developers) should focus on creating software and not on packaging. And as @b4n said before, if volunteers like @fusion809, @ecmu, @probonopd and whoever else might want to step in and provide AppImages, Flatpaks, Snaps, ZeroInstalls, ... that's completely fine.
However, I don't see that those packaging efforts should happen within the Geany project itself.

We could easily add the AppImage to https://www.geany.org/download/third-party/ so that it gets more visible. Than we are done with five minutes of work.

[probonopd]

The AppImage team provides tools for upstream packaging, so that the original authors of applications can provide binaries with end-to-end control over the all aspects of the distribution.

As a a general best practice measure for security, we discourage people from downloading software from "random places" which is everything but the original authors's download page.

@ecmu has already put in the work and has made https://github.com/ecmu/geany.AppImage/blob/master/.travis.yml. Now it is a question of whether the Geany team would accept a PR to the official repository so that the AppImages would be officially created (and supported) by the Geany team.

We could easily add the AppImage to https://www.geany.org/download/third-party/

This kind of endorsement of a third-party AppImage might be a pragmatic compromise so that people know the build can be trusted, although officially created (and supported) binaries should always be preferred.

---

As a testament to the quality of the Geany AppImage, here we have the Geany (for Linux) AppImage running on FreeBSD helloSystem:

[elextr]

Basically the Geany team does not have the effort available to support distribution, be it appimage, or flatpack, or snap. If somebody wants to make such distributions elsewhere, fine, but as @eht16 said the Geany team do not accept the extra workload.

The AppImage team provides tools for upstream packaging, so that the original authors of applications can provide binaries with end-to-end control over the all aspects of the distribution.

To be clear, the original authors do not want to have end to end control of the distribution, distribution is not our thing, Geany is a volunteer project where contributors work on what they want to, and so far most contributors have indicated no interest whatsoever in distribution. So including any distribution support in the main Geany repository is not desired. The only distribution in the Geany repo is windows, for historical reasons, and because it also requires source changes to support windows (see all the #ifdefs). Even the OSX build is outside the main repository.

What I personally think might possibly be done (don't know what others think) is to provide another repository under the Geany organisation where someone who wants to support appimages can make them, similar to the way OSX is handled. But somebody has to offer to continue to support releasing them.

[ecmu]

I agree to volunteer in the support of Geany AppImage inside Geany organisation if this is possible.
I am not an expert in github so I will need help to do that. Let me know...

[kugel-]

IMO it would be good to have @ecmu work in the geany organisation, but in a separate repository.

To me its like the MacOS images. We provide them, more or less with official blessing, but when it comes to support we must offload to @techee. At least the repo has its own set of issues and PRs

[eht16]

I'm not generally against having an AppImage repository under the Geany organisation, I just don't see the benefits and why it's worth the efforts to migrate the already existing repository.

I guess there will be the "official" argument but does it really matter that much? Despite the general perception, technically it makes no difference and might be even a wrong suggestion to the user. Why would be an AppImage repository in the Geany repository be more official than a repository elsewhere? It's still someone else who maintains it and there is not more or less QA, I think.

Apart from that, I would recommend to not build new images on each push to PRs or master branch. This seems like a huge waste of resources. Additionally, when Travis CI is used, you'll probably running out of free credits quickly. Migrating to Github Actions could be a solution, I'm going to propose this also for the Geany repositories.

[elextr]

Apart from that, I would recommend to not build new images on each push to PRs or master branch.

Yes thats why I suggest a different repository, its separate, so like Geany plugins doesn't get rebuilt with every Geany PR. Plus the points @kugel- noted. Now github allows transferring issues I just slide Mac ones to that repository.

Additionally, when Travis CI is used, you'll probably running out of free credits quickly. Migrating to Github Actions could be a solution

Agree it should use Github actions if being in the Geany organisation uses Geany Travis credits. That should happen before the repository is migrated.

I'm going to propose this also for the Geany repositories.

Another issue, but agree it should be examined/tested.

Despite the general perception, technically it makes no difference and might be even a wrong suggestion to the user.

True, and at the moment the @ecmu scripts wget stuff from all sorts of places, that needs to become traceable if users are to be able to trust the resulting appimage.

[andy5995]

I'm not generally against having an AppImage repository under the Geany organisation, I just don't see the benefits and why it's worth the efforts to migrate the already existing repository.

One option that may bear further discussion is what @eht16 mentioned above:

We could easily add the AppImage to https://www.geany.org/download/third-party/ so that it gets more visible. Than we are done with five minutes of work.

[eht16]

New year, new luck :D.

geany/www.geany.org#42 will add the AppImage from @ecmu to the Third Party packages list on the website. Feel free to comment in the PR, also to extend/improve the steps to get it running.