AppImage

Option to be "modern" (ie. 20.04) with appimages

Creating AppImages
#1

Hi. First, thank you to the team for providing this super cool packaging alternative.

My background: 40 years programming, mostly with pascal. Linux knowledgable, but not a linux expert.

Backstory: modernizing (ie. bug fixing) a program I wrote 2 years ago and I want to use appimage deployment. I am building against Kubuntu 20.04. Yes, I know that is not allowed as regards the rules, and that I will be banned from the appimage.hub. And that is my question, perhaps it could be allowed to be “modern” and go forward from this point?

I cannot go back to ubuntu 16.04 because due to various bugs in my programming platform and needs of my program as regards today, it is not feasible/possible to compile it under 16.04 and also not under 18.04!

I have a working appimage now, that I have tested against Kubuntu 20.04, Ubuntu 20.04, fedora 32, Current nixOS (requires however appimagerun but not a problem), current manjaro, and current OpenSuse Leap. All work great, except OpenSuse Leap, which has a glibc version < 2.31. But I’m positive my app will work as soon as OpenSuse releases a newer version with newer glibc.

I did have to fiddle a bit to make the appimage work under fedora 32, but it was pretty simple actually.

So, I am quite happy (ecstatic acually) that I can deploy to, basically, ANY (modern) linux distro, that is so cool. But that is why I wonder if it would be a possible idea to have a section of the appimage.hub for maximum compatibility with LTR distros alongside a “going forward from now” section? And this would mean that all the app image tools would need a switch allowing what are now considered “blacklisted” libraries to be allowed.

As I inspected the output from linuxdeploy I saw a lot of bypassing of “blacklisted libraries” (among which, for example, was the glibc 2.31). So that means my appimage is not “complete” in that it will depend on the deployment distro’s glibc version and not any deployed in my appimage. And I wonder that will break my appimage as soon as a distro has a > 2.31??

So for me, because I will need to host it myself for download since appimage hub wouldn’t accept it, it would be very nice it I could have a switch that says “it ok to build” against my current environment which is, as I said, kubuntu 20.04.

Thanks for listening. I’m not always online so I may be slow to answer any questions so your patience is appreciated. BTW, fwiw, I intend to author another post regarding some questions I have regarding the linuxdeploy output.

1 Like
#2

Hello @Juuliuus, thanks for your post here and for giving some context.

What is always surprising me is why some developers choose to develop (and build) on the latest-and-greatest systems, rather than on the “least common denominator” that one can expect all users to have.

You are saying you have 40 years programming background. Then I am sure that you understand the concept of “backward compatibility”.

I cannot go back to ubuntu 16.04 because due to various bugs in my programming platform and needs of my program as regards today, it is not feasible/possible to compile it under 16.04 and also not under 18.04!

This argument I personally always find a bit hard to believe, I guess that some developers just use whatever happens to be installed on their private development machine, only to discover after the fact that they have inadvertently introduced dependencies on the latest-and-greatest… or maybe this is what you mean by “needs of my program as regards today”. Or are you saying that you would have been unable to write your software in 2016 because the tools available at that time were just not sufficient?

In any case, like so many things in engineering, this is all about trade-offs.

With my tools, I want to enable people to build binaries that will run on all still-supported mainstream Linux distributions. I have no interest in putting out tools that allow developers to make binaries that will run only on the very latest Linux distributions.

This means that either the binaries are compiled on the oldest still-supported mainstream Linux distribution (= currently Ubuntu xenial), or that we bundle everything privately inside the AppImage (all libraries, including those which can be expected to come with all Linux distributions).

Generally I have been recommending the former, but in your use case you could use the latter.

I am working on a new tool that allows you to do that - but be aware that it is still in the early stages so you might run into bugs, in which case I’d ask you to file an issue on GitHub.

Thanks!

Especially check out the -s deploy switch. It causes the libraries in the excludelist to be not excluded. In other words, you will get a larger AppDir/AppImage with all libraries.

./appimagetool-*.AppImage -s deploy appdir/usr/share/applications/*.desktop # Bundle EVERYTHING
#3

Hi, thanks for the answer.

Your solution (at the end) is exactly what I was looking for!

Yes I am familiar with backward compatibility. But, literally, in this case, I can NOT go back to either 16.04 or 18.04. The reason is my development platform is the Lazarus / free pascal project. I absolutely love this project, the IDE is wonderful, etc. But. It is a work in progress and the versions available for development in 16.04/18.04 make it extremely unfeasible (due to bugs in localization) to go there based on my project needs.

So what I want to do is, yes, build around this “modern” 20.04 release. But, I do not intend to do this every year. In other words, in around 2028 I will be eligible for the Appimage Hub because then I will be supporting the “oldest” still supported release.

I want to get into the sytem now and go forward, not go 4 years back. This does actually pain me, I agree it would be wonderful to be able to run on 16.04’s. But my trade-off in this case was that I had to face the reality that my software couldn’t be released in this method at all, and I’d have to look for other (flatpack/snap/normal) packaging methods.

I will be downloading and testing the -s switch, so a really big thank you for providing that!

#4

See?

The prudent thing to do would imho be to bring the very latest version of Lazarus onto all still-supported Linux distributions, not just the latest-and-greatest.

Maybe the Lazarus team would like to make an AppImage, which would allow you to run it on 16.04?

#5

Yes I certainly do see. It will take a while to get these kinds of relationships built however.

BTW, one of the many complaints one sees about pascal/Delphi/Lazarus is “the executable is so big!” (think, for example, about 6 Mb). The idea behind this is precisely the idea behind AppImage: the executable just runs, everything it needs is packed inside (except for one tiny exception on qt builds, a qt lib for pas). I’ve always been a fan of this kind of idea because of dll hell.

1 Like