Use static binaries for all ingredients

[probonopd]

A long-term complaint about AppImage has been that our tools don't run on non-glibc systems, need to be built in Docker containers with ancient build host systems, and can break anytime when distributions cease to ship (or do major upgrades of) some of the "low level" libraries.

Hence I am proposing that we replace all ingredients of the AppImages that get produced by this repository with static ones.

Wdyt @TheAssassin @azubieta @Tachi107?

On https://github.com/probonopd/static-tools/ @Tachi107 and I have been building static binaries (using Alpine Linux and musl libc) for many of the ingredients already, plus some binaries that we were not able to bundle previously like appstreamcli.

[probonopd]

If we then also manage to also have static builds of the runtime and AppRun, then we are no longer dependent on Docker containers with ancient build host systems at all, and breakages like the libfuse2/3 debacle should not happen anymore. As a nice side effect, the AppImage tools would then also work on non-glibc based distributions.

[TheAssassin]

need to be built in Docker containers ancient build host systems

That is not a "complaint about AppImage", because third parties don't have to work with this infrastructure, and the tools can be built just fine on modern OSes. The framing is inappropriate. This is your personal opinion, as far as I can see.

Hence I am proposing that we replace all ingredients of the AppImages that get produced by this repository with static ones.

This repository doesn't produce any third-party binaries. Those are managed in https://github.com/AppImage/AppImageBuild.

---

As far as I can see, you want to:

• eliminate AppImageBuild (a repo that has served us well for many, many years, by the way...)
• ship static versions of tools called by appimagetool (this is implied by eliminating AppImageBuild)
• build appimagetool statically (also implied by eliminating AppImageBuild)
• build the runtime statically (should be tracked in a separate issue)

In your original post, you're mixing all these points, apparently to make a point that the runtime and appimagetool should be static binaries. This is confusing, and the justification is misleading. After all, the proposed way is just one option, all the issues you mentioned can be solved otherwise, too. This is more of a "long term strategy".

IMO, the runtime should never have been included in this repository anyway. I just don't find the motivation nor the time to work on type 3, which would solve a large variety issues, including solutions for current supply chain problems...

Anyway. Any work in this direction needs to begin by changing the build infra to use some up-to-date stable (LTS) distribution and deprecate AppImageBuild this way (which is only used by us in this repository, as far as I remember).

Next, since the tools we built in AppImageBuild are no longer available, static tools must be deployed as a substitute, distro tools will not work in the long term (but they'll work well enough while removing AppImageBuild from the CI). Dependencies on third-party repositories make little sense from our perspective, though. One reason to build and publish Docker images in AppImageBuild was to "cache" built dependencies so they do not have to be rebuilt every time. Your repository could serve as a replacement

These points need to be finished first to make sure the repository is ready to publish static binaries. There is some work to be done here, obviously, but it's necessary to eliminate any broken, outdated CI infrastructure first. Otherwise, I anticipate that CI will be a huge mess again.

Of course, the work needs to be done outside master so the continuous release stays online.

[probonopd]

That is not a "complaint about AppImage", because third parties don't have to work with this infrastructure, and the tools can be built just fine on modern OSes. The framing is inappropriate. This is your personal opinion, as far as I can see.

It's not my complaint at all. After all, I know why we did it and why we deemed it necessary at the time. But I hear it from people who use points like this to point out that AppImage is "based on hoping", "not sound engineering", etc.

So what I would like to achieve is a static runtime and an AppImage that contains only static binaries, and do it in a very lightweight way.

For now, I will concentrate on using https://github.com/probonopd/static-tools/ as a test so see how far we can get things by using Alpine Linux and musl libc for building as many things statically as possible.

Let's see how it goes.

[probonopd]

There are now experimental AppImages using a static runtime and containing only static binaries.
In theory, they should be able to run on non-glibc systems and on systems with very unusual filesystems like NixOS.

If you would like to test, please let me know whether it works for you:
https://github.com/probonopd/go-appimage/releases/tag/continuous

@TheAssassin in my experimental go-appimage implementation:

• eliminate AppImageBuild
• ship static versions of tools called by appimagetool (this is implied by eliminating AppImageBuild)
• build appimagetool statically (also implied by eliminating AppImageBuild)
• build the runtime statically (tracked in a separate issue)
• eliminate Docker (WIP)
• eliminate chroot (WIP)
• eliminate CMake (WIP)
• improve build times (WIP)

[probonopd]

...and we are running on NixOS