No longer add AppImages that require libfuse2

[probonopd]

At some point in time, we should probably no longer add AppImages to the catalog that require libfuse2, or at the very least give a warning.

Wdyt @TheAssassin @ivan-hc @Samueru-sama?

[ivan-hc]

When I can and if I can, I try to suggest to developers the use of the new appimagetool. The problem persists in those projects where Electron-based AppImages are "mass" produced, as developers still rely on old tools.

I remember that we have already tried to "force" the use of this tool, but without success. In fact, the developers either used the "legacy" version by changing the link, or threatened to stop producing it.

Where I could, I tried to recreate new ones myself, unofficially, of course.

In my "AM" package manager I offer the option to convert these old AppImages using the new appimagetool ("nolibfuse" option), and I identify packages that need such a library in the installed apps table (-f or files option), and in both cases I suggest users upgrade.

If so many still exist, it is clear that much attention is not being shown to the message. At the same time, there are too many developers who ignore this possibility, and persistently continue to create old AppImages.

[Samueru-sama]

At some point in time, we should probably no longer add AppImages to the catalog that require libfuse2, or at the very least give a warning.

that should have happened 2 years ago.

now is the second best time.

[probonopd]

Well. As a developer I don't like a "moving target", and if changes are made, I need time to accommodate. So with AppImage, I likewise want to give other developers time to accommodate. This being said, I think the time has come, sooner or later, or maybe right about now.

[Drsheppard01]

Almost all Electron applications are built using Electron-Builder, which in turn uses obfuscated code and is tightly coupled to version 13 of AppImageKit, making it impossible to run AppImage without Libfuse2.

[ivan-hc]

Almost all Electron applications are built using Electron-Builder, which in turn uses obfuscated code and is tightly coupled to version 13 of AppImageKit, making it impossible to run AppImage without Libfuse2.

I see, this has gone nowhere electron-userland/electron-builder#8686

I have not understand if they want to ignore the issue or simply are unable to fix it themself. @Samueru-sama has also linked a solution there, so all this made me think about the first.

[ivan-hc]

The problem is that the conversation about AppImages has died down for a couple of years: I haven't heard anyone talk about developments in the AppImage ecosystem. The classic tools have remained practically the same, and the major media have decided not to talk about AppImages anymore (except in tutorials that focus on using Fuse2 on new versions of Ubuntu).

I think what's missing is good information. News about improvements to the ecosystem needs to be spread! YouTube, websites, blogs, and the like need to get this information from someone with influence on the topic. And who better than @probonopd to spread this news?

We're nobody, but you're the one who invented AppImages.

It's time you spoke up again, aware of the efforts we're making to keep the AppImage format alive.

If you don't speak up, we'll just open issues and discussions "among ourselves," forcing AppImage into a niche product, because that's what it's becoming today, under the pressure of Flatpak, Snap, and their proponents.

We know how good AppImages are today; it's time others learned the same.

[ivan-hc]

We know how good AppImages are today; it's time others learned the same.

"others", that is, developers who still use old packaging methods because they're unaware of new ones.

AppImageKit is the most reliable source for them; they know nothing about the new appimagetool, and if Samuel or I suggest it to them, they look at us with suspicion, because we're nobody.

[ivan-hc]

In my "AM" package manager I try to suppress the libfuse2 problem like this

https://github.com/ivan-hc/AM/blob/0753c68ae8e72ee486d458864308e6c730cdb648/modules/management.am#L356-L430

This is something I already do for Libreoffice, actually, and unofficially (see the description here https://github.com/ivan-hc/LibreOffice-appimage ), because, after contacting the current maintainer via email (he's also Italian, like me) and seeing that things haven't changed... I realized that not everyone is capable of doing it.

As a workaround, in my package manager, I allow conversion of old AppImages using the new appimagetool, and it works great.

get-rid-of-libfuse2-2024-08-18_22.09.08.mkv.mp4

Perhaps a converter like this, in a script that extracts and repackages old AppImages, could serve as a temporary solution.

Developers still stuck with the old methods can simply add a script with this to their workflows.

Something like this would suffice (for now).

[ivan-hc]

Something like this would suffice (for now).

But obviously, the message needs to get out. Preferably from authoritative sources.

[probonopd]

I see, this has gone nowhere electron-userland/electron-builder#8686

I submitted a PR:

• chore: Update AppImage runtime electron-userland/electron-builder-binaries#100

[ivan-hc]

I see, this has gone nowhere electron-userland/electron-builder#8686

I submitted a PR:

chore: Update AppImage runtime electron-userland/electron-builder-binaries#100

One ring to rule them all - The Lord of the Rings

[ivan-hc]

@probonopd what about appimage-builder?

Also if the correct appimagetool has been added AppImageCrafters/appimage-builder@2a2269e there is no new release since 2022 https://github.com/AppImageCrafters/appimage-builder/releases

Also, there is no github workflow ended successfully https://github.com/AppImageCrafters/appimage-builder/actions so maybe it is a problem with the CI if newer changes have not been added AppImageCrafters/appimage-builder@Continuous...main

[probonopd]

what about appimage-builder?

That'd be a question for @azubieta :)