Writing in releases "DO NOT USE ANYMORE" is not enough, almost nobody will read it!

[ivan-hc]

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

[Drsheppard01]

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

[TheAssassin]

I've always been in favor of just breaking those projects then.

[Drsheppard01]

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

[Samueru-sama]

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: electron-userland/electron-builder-binaries#57

[TheAssassin]

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.

[Drsheppard01]

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

[probonopd]

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.

[mmaietta]

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

[probonopd]

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!

[Samueru-sama]

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

[Drsheppard01]

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

[ivan-hc]

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.

[TheAssassin]

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

[probonopd]

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.