AppImage
Writing in releases "DO NOT USE ANYMORE" is not enough, almost nobody will read it!
Your appimagetool is still used in several projects that continue to use it unaware of the new developments.
I suggest you update this runtime as well, or publish a "fix" release, or upload this directly https://github.com/AppImage/appimagetool
But majority of devs has ci with appimagekit and they can't check main repo because it's just worked (not, but it's details). When something is broken in appimage ci they just delete ci worker instead improve it
I've always been in favor of just breaking those projects then.
Great idea, now we can just remove appimage/appimagekit without any notice, we're cool than ubuntu (which can break appimage integration), 'cuz appimage for all distros and the're more appimage users than ubuntu users
One big project is libreoffice, it is still using the appimagetool from here: https://bugs.documentfoundation.org/show_bug.cgi?id=165735
EDIT: Libreoffice fixed it.
Another holdout is electron builder: https://github.com/electron-userland/electron-builder-binaries/pull/57
Great idea, now we can just remove appimage/appimagekit without any notice, we're cool than ubuntu (which can break appimage integration), 'cuz appimage for all distros and the're more appimage users than ubuntu users
I don't think I understand what you want to tell us. But to extend my previous statement: let's just remove said release. Once things start to break downstream, people might take action. Otherwise, "it works" is just going to be like that forever.
A less "annoying" way would have been to advertise the move in the binaries, but that would have required to take action before the last restructuring.
Most of the apps packaged in ApppImage are apps made through Electron Builder, which use their older version of Appimagekit from releases. Another significant portion uses appimagebuilder which is effectively dead by now but still used by some developers, the latter portion uses self-written scripts that were written by interested people, such build scripts may not be updated for years, and if we remove appimagekit they will probably just be removed and not built.
In the current situation, it's hard for me to form a position, since a build script that doesn't work properly is better than no build script at all. Finding all the application build scripts that use the old version of appimagetool and rewriting them using the new version is a challenge
Personally I value not breaking things very, very much.
We deliberately designed things so that changing to a newer runtime is a voluntary, proactive act on the part of whoever uses the runtime (opt-in).
The proper thing to do is to inform whoever is still using the old runtime that it should not be used anymore, and why.
Maintainer of electron-builder here and looking to update the AppImage runtime binaries in the electron-builder-binaries repo.
From what I'm reading here, it sounds like there's an alternative to appimagekit? Is that appimagetool now and runtime is no longer needed? Apologies if that is a naive question, I'm fairly new to the AppImage developer-side of affairs and am simply looking to update electron-builder's toolset
Hi @mmaietta. The appimagetool in this repository, AppImageKit, has been deprecated.
We just leave it here so that existing CI builds don't break.
The new one is in https://github.com/AppImage/appimagetool. It automatically downloads the runtime from https://github.com/AppImage/type2-runtime, though this is an implementation detail that might or might not change in the future.
Hope this clears it up. Feel free to ask any questions!
You might really want to make the message more clear.
@danirabbit who is the founder of elementaryOS recently made a post on mastodon that people should stop using appimages because of the libfuse2 dependency...
I think the main problem is that we don't have an appimage build system, only different methods and collections of scripts. Of the current ones, pkg2appimage is the most similar to a build system (reading recipes and building according to them), but it doesn't use type-2 runtime
I opened this to report the problem: people continue and will continue to build AppImage packages using your tool, wrongly. AppImages based on this method will continue to depend on the now obsolete FUSE2, and smear campaigns against AppImage and in favor of other packaging formats will increasingly gain traction!
OK, I acknowledge that.
Honestly, it's frustrating to know the potential of AppImage and see its creators so detached and resigned to the idea that their project doesn't stand a chance against Snap and Flatpak.
I've produced and maintain over 90 AppImage packages in my repositories, which are unofficial and will remain so, precisely because I've had the good sense to read the developments of the AppImage ecosystem, unlike many upstream developers. And if I'm writing here, it's because I understand that there are only a few of you left, and I'd like to help and work with you, to the extent I can.
I really don't know what to do with you anymore.
For now, I'll close this issue as "unplanned," because that's what I've understood so far: you don't plan to break away from the common misconception that AppImage relies on obsolete libraries.
It's disappointing and frustrating, you know?
Bye.
@ivan-hc my own resignation about the maintenance of AppImage is also fueled by such decisions... but what should I do? Delete the release and wait for @probonopd to recreate it? It makes absolutely no sense to me to keep every damn pipeline that people forgot about running and not fixing the problem.
Initially, we did not even make releases to make sure that people use the latest files. But this is undermined completely by the continued existence of this release.
I think I found a way to reduce frustration on all sides by renaming the binaries, prefixing them with obsolete-.
That will break existing CI pipelines. Not something I do lightheartedly, but apparently not doing it isn't painless either.
This approach at least allows affected CI pipelines to be fixed by just adding obsolete- to the filename again in case they are not ready for whatever reason yet to use the new version of appimagetool.
Hope this works out at least reasonably well for everyone. Sorry for the trouble this has caused. We shall try to do better in the future and not have such breaking changes anymore.
The inconvenience lies in continuing to allow users of appimagetool to generate known-broken AppImages...
They are not "broken", they are just like they used to be before we came up with newer stuff. Anyhow. I hope this is solved now.
Hi everyone, I inherited an open source project but I am not a Linux user, I used this pre-existing GitHub workflow to create appimages.
- https://github.com/ciromattia/kcc/blob/master/.github/workflows/package-linux.yml
Looks like this change caused my builds to fail, can anyone help me fix it?
Here are the error logs: https://github.com/ciromattia/kcc/actions/runs/16408903373/job/46359955017
Hi everyone, I inherited an open source project but I am not a Linux user, I used this pre-existing GitHub workflow to create appimages.
* https://github.com/ciromattia/kcc/blob/master/.github/workflows/package-linux.ymlLooks like this change caused my builds to fail, can anyone help me fix it?
Here are the error logs: https://github.com/ciromattia/kcc/actions/runs/16408903373/job/46359955017
Oh boy appimagebuilder was downloading the runtime directly from here.
This PR should have fixed However appimagebuilder hasn't had releases since 3 years ago 😭
This PR should have fixed However appimagebuilder hasn't had releases since 3 years ago 😭
This is exactly the reason why I didn't want to take such "drastic" action as to break existing CI pipelines.
What are we gonna do if appimagebuilder (and possibly other tools) will never be updated? Maybe we should write a script that fetches appimagetool and puts it as a release into this project?
Maybe we should write a script that fetches appimagetool and puts it as a release into this project?
No, I disagree strongly. That has been discussed and found to be a bad idea.
We've been using pkg2appimage up until now, but found our builds are now failing. What's the upgrade path for users in our situation?
We don't have much experience with building AppImages, so sorry if this is a totally naive question
We've been using pkg2appimage up until now, but found our builds are now failing. What's the upgrade path for users in our situation?
We don't have much experience with building AppImages, so sorry if this is a totally naive question
@Thomas101 an issue is opened for this, waiting for an answer https://github.com/AppImageCommunity/pkg2appimage/issues/571
@Thomas101 would you like to send a PR that just updates the download URL for appimagetool? I'll happily merge it ASAP.
Oh boy appimagebuilder was downloading the runtime directly from here.
This PR should have fixed However appimagebuilder hasn't had releases since 3 years ago 😭
Looks like that PR didn't fix it.
- https://github.com/AppImageCrafters/appimage-builder/issues/375#issuecomment-3095997559
Actually, pkg2appimage has been using the new appimagetool for quite a while. @Thomas101 you should just update or open an issue there. We are discussing in a dead PR.
Regarding appimagebuilder, CCing @azubieta.
Oh boy appimagebuilder was downloading the runtime directly from here.
This PR should have fixed However appimagebuilder hasn't had releases since 3 years ago 😭
Looks like that PR didn't fix it.
* [Please release new version to pypi AppImageCrafters/appimage-builder#375 (comment)](https://github.com/AppImageCrafters/appimage-builder/issues/375#issuecomment-3095997559)
The PR didn't update all links 🤦
https://github.com/AppImageCrafters/appimage-builder/blob/main/appimagebuilder/modules/prime/appimage_primer.py#L102
If someone has some spare time to help a project with linuxdeploy issues, please have a look at the comments in https://github.com/tauri-apps/tauri/commit/89cb2526409d3b88e0aa15b93e4d26b09d9c0373 Thanks!
To those who pressured me to break existing CIs workflows, please have a look at https://github.com/AppImageCrafters/appimage-builder/pull/376. This is exactly why I didn't want to do it.
Hmpf, I would like to have reproducible builds for our AppImages, this is now impossible with the "Continuous" strategy that AppImage is following.
I am also not really sure about supply chain security either if the releases are created and signed by a github action and it's impossible to use a known-good hash (or immutable releases once that's a thing), because there is no tag...
What is the path forward? Do I really fork the AppImage eco system just to get stable releases or do other people have a similar feeling as well and there is already a solution?
