#375 Update url for AppImage tool

[mrRedSun]

CI is failing for me with the old URL, so I updated it to the new one that AppImageKit recommends. Please review and let me know if anything needs to be adjusted. Fixes #375

[mrRedSun]

@azubieta could you take a look?

[guihkx]

Perhaps we could have a mechanism (e.g. environment variables or cli options) to override this and other URLs that are currently hardcoded in the program, because the removal of the old URL broke hundreds (if not thousands) of CI workflows. And for what reason? @probonopd

Even if this is fixed now, who guarantees it won't happen again in the future?

[mrRedSun]

@guihkx, to be honest, the URL shouldn't break, and the package should be maintained. For my container, I just did a patch in Dockerfile with
RUN find /opt/appimage-builder -type f -name "*.py" -exec sed -i 's|AppImageKit/releases/download/continuous|type2-runtime/releases/download/continuous|g' {} \; -exec echo "Updated {}" \; || echo "No changes made to {}"
which isn't great, but did the trick for now, but the problem is, the latest binary release is from 2022, and that release doesn't work for me, so I use the code from master anyway

The main problem is that this tool is quite niche, and no one wants to maintain it

[guihkx]

I understand this tool might not have an active maintainer anymore, but I disagree that it's niche:

https://github.com/search?q=AppImageCrafters%2Fappimage-builder&type=code

What's also not clear to me is why the URL was removed from AppImage/AppImageKit and moved to AppImage/type2-runtime in the first place...

[probonopd]

Please use zstandard compression.

[Samueru-sama]

because the removal of the old URL broke hundreds (if not thousands) of CI workflows. And for what reason? @probonopd

The reason is because a new runtime was made, this new runtime is static and no longer has a libfuse dependency. It has also been around for several years but very few projects have adopted it.

The change came as result of this issue: AppImage/AppImageKit#1395

Why this moved to separate repo I don't know, however I made this PR that would fix most instances of broken CIs: AppImage/AppImageKit#1407

I don't think it will help here since it seems appimagebuilder only provides gzip and xz comp?

Perhaps we could have a mechanism (e.g. environment variables or cli options) to override this and other URLs that are currently hardcoded in the program,
Even if this is fixed now, who guarantees it won't happen again in the future?

appimagetool provides the --runtime-file flag which lets you choose a different runtime. No idea if appimagebuilder has something similar.

Another solution is to use appimagebuilder to just deploy the dependencies and then use appimagetool to turn the AppDir into an appimage, hopefully appimagebuilder has that option.

[guihkx]

@Samueru-sama I appreciate the explanation; I was truly not aware a newer runtime even existed.

And while is undoubtedly an improvement upon the "old" runtime, in my opinion that's still not a good reason to deliberately break every CI workflow out there, especially when the "old" runtime still works perfectly fine. Perhaps a less aggressive solution would be updating the old runtime to print a warning asking devs/packagers to switch to the new runtime, or something like that.

But alas, what is done is done.

I would just suggest AppImage devs to consider dropping the misleading "continuous" tag from the runtime releases, and instead give us fixed runtime releases. Because if shiny new features are all it takes for you to break every CI workflow out there, at least give us the choice to stick with the old smelly thing.

[Samueru-sama]

especially when the "old" runtime still works perfectly fine.

The old runtime no longer works on most distros unless the user manually adds libfuse2, that is not perfectly fine.

and instead give us fixed runtime releases.

You can also use this if you want fixed releases: https://github.com/VHSgunzo/uruntime

The squashfs version is a perfect drop in replacement, we are using it for all appimages here

EDIT This one also supports xz and gzip comp iirc.

[guihkx]

The old runtime no longer works on most distros unless the user manually adds libfuse2, that is not perfectly fine.

But AppImage's dependency on libfuse2 has been known since its inception, so in my opinion that's still not a good justification to break everyone else's CI workflows.

My question is: Can we trust the AppImage devs not to deliberately break stuff again in the future under the guise of "improving things"?

FWIW, I still do appreciate you linking those alternatives, and I'll take a look at them. However, I still maintain that this move by the AppImage devs was ill‑advised, and it's likely to drive many other devs away from AppImages.

[Samueru-sama]

But AppImage's dependency on libfuse2 has been known since its inception, so in my opinion that's still not a good justification to break everyone's CI workflows.

To this day I still see people having this issue needing help.

And also I've see a few that break their entire system because they install fuse2 instead of libfuse2 in ubuntu and similar and apparently that wrecks havoc because on ubuntu you cannot have fuse2 and fuse3 installed together.

My question is: Can we trust the AppImage devs not to deliberately break stuff again in the future under the guise of "improving things"?

That I can't answer. I also don't know why it was split into several repos instead of continuing at AppImageKit.

and it's likely to drive many other devs away from AppImages.

I would honestly prefer that than what I see very often, which is devs pushing very broken appimages and refuse to fix the issues.

One example is Azahar, that appimage is being built on a version of debian that is too new, so it doesn't actually work for most people, I actually offered myself to help the dev to fix this issue for good and the dev refused and keeps closing multiple issues about it, so I went and made a separate repo doing the right thing.

I will also add that I have not been able to test a single appimage made with appimagebuilder that works on my system. And I'm using a fork of archlinux so my distro isn't that weird.

So yeah I would hate to see that, but also a lot of those devs usually make very broken things that don't work for me at all.

[mrRedSun]

I would agree with @Samueru-sama that all of the complexity should be on the dev side, not the user side. AppImage was supposed to be an easy way for everyone to use applications on Linux, no matter the distro, but having to install fuse is anything but user-friendly

[Samueru-sama]

but having to install fuse is anything but user-friendly

I would also like to mention that the uruntime that I linked previously has something that even if FUSE is not installed on the system at all the appimage is still able to work. Because it falls back to extract and run with self cleanup.

I often see a lot of devs (not users) that deploy appimages in docker containers and as result FUSE is not available, so what they often do is take appimagetool and extract it manually, then run the squashfs-root/AppRun to work around that.

You don't have to do that ever, if you set the env variable APPIMAGE_EXTRACT_AND_RUN=1 it will self extract to /tmp and run but very few people know about this variable, nobody reads the documentation after all 😆

I talked about it a while back that this should be automated as well in the type2-runtime but iirc @probonopd refused because he worried that people would just keep their FUSE setup broken forever, which I don't think it is a good excuse, if you are using an appimage is because you want download and run the f*cking thing and not worry that the thing might use more RAM when it extracts instead of mounting and similar...

anyways, sorry about the rant.

[mrRedSun]

anyways, sorry about the rant.

All good, thanks actually, very informative, this PR is never getting merged anyway, glad I still learned something from this situation :)

[Samueru-sama]

@DevilXD I will respond here since you decided to close comments after spreading false information.

DevilXD/TwitchDropsMiner#731 (comment)

Intentionally breaking the builder because of "the great new and upgraded lib" is out now and available, doesn't really feel like a valid argument to me

This was not intentional, if you see: bf6123e

and

AppImage/AppImageKit#1395 (comment)

and

AppImage/AppImageKit#1407

We did not know appimagebuilder was abandoned.

In fact the original issue was about appimagetool and not the runtime files.

Also I never said "why no update in 3 years", I responded:

You haven't had time in 3 years???

to @guihkx comment that "After all, not all of us have an infinite amount of time to keep up with AppImage changes."

regardless of the 4 MiB of space saved

this is totally unrelated, this change itself doesn't reduce that.

It was in response to @guihkx lie that bundling glibc makes everything use 500 MiB of RAM.

Never I would have imaged this amount of nonsense from people that should know better.

[mrRedSun]

[MrAdrianPl]

just as a information I've by trail and error made docker image of appimage-builder for CI,
it has issues but its able to generate appimages so as a temporary solution if anyone wants to use it then here's my fork
https://github.com/MrAdrianPl/build-appimage

notes to the version:
recipe cant take version argument in runtime section so it defaults to V2.0.0
comp parameter is required it takes None XZ and Gzip as an inputs

I'm counting on that somebody will make bit improved version

sorry for a bit of an off-topic from the original discussion clue

[probonopd]

Thing is, only @azubieta can merge PRs in this project and he hasn't been very active on GitHub in the last moths; I pinged him over other channels. Maybe he can have a look. Thanks for your patience.

[azubieta]

Thanks!

[probonopd]

Thank you @azubieta. For it to work though, #378 also needs to be addressed. Thank you so much!