F44 Change Proposal: Atomic Desktops: Drop FUSE 2 libraries [SelfContained]

Project Discussion Change Proposals
, ,
1

Atomic Desktops: Drop FUSE 2 libraries

Wiki

Announced

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary :open_book:

Remove FUSE 2 binaries and libraries from all Atomic Desktops as the FUSE 2 version of the project is deprecated and not maintained anymore.

Owner :open_book:

Detailed Description :open_book:

Remove the fuse and fuse-libs (FUSE2) packages from Atomic Desktops. No packages depends on it since they all moved to FUSE 3 during the Fedora 40 cycle. We manually kept those packages included to keep compatibility with old (type-1) AppImages. See:

AppImage that are built with the type-2-runtime do not require the fuse2 libraries anymore thus we can now remove them from Atomic Desktops.

Feedback :open_book:

While we don’t officially support AppImage nor recommend using it (as we recommend using Flatpaks), we manually kept those packages included to keep compatibility with old (type-1) AppImages for a while. Three Fedora releases have now passed since the initial reports thus AppImages would have likely been updated since then:

For old AppImages, users have some fallback options or they can layer the fuse2 packages.

Benefit to Fedora :open_book:

Smaller images for Fedora Atomic Desktops and less legacy, unmaintained software included.

Scope :open_book:

  • Proposal owners: Remove the fuse2 packages from Atomic Desktops
  • Other developers: N/A
  • Release engineering: N/A
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with the Fedora Strategy: General improvement for Atomic Desktops

Upgrade/compatibility impact :open_book:

Users that rely on old AppImages will have to update them, use a fallback option or layer the fuse2 packages.

Early Testing (Optional) :open_book:

Do you require ‘QA Blueprint’ support? N/A

How To Test :open_book:

You can get the runtime of an AppImage with the --appimage-version command line option (see AppImageKit#command-line-arguments). Example for the Krita AppImage:

$ ./krita-5.2.14-x86_64.AppImage --appimage-version
AppImage runtime version: https://github.com/AppImage/type2-runtime/commit/2df896e

Remove the fuse and fuse-libs packages locally. Verify that AppImage applications still work or consider using the Flatpak version if it exists or report issues to the developers upstream.

User Experience :open_book:

Users of old AppImages may have to update them or try fallback options.

Dependencies :open_book:

None.

Contingency Plan :open_book:

  • Contingency mechanism: (What to do? Who will do it?) Revert the change. The Atomic Desktops maintainers will do it.
  • Contingency deadline: N/A (not a System Wide Change) but Beta/Final freeze
  • Blocks release? N/A (not a System Wide Change) but No, can be easily reverted

Documentation :open_book:

See release notes.

Release Notes :open_book:

FUSE2 librares and binaries have been removed from all Atomic Desktops. If you have applications (notably AppImages) that depend on those libraries, please update them, consider using the Flatpak version if it exists or ask upstream to update them to the newer AppImage runtime.

Last edited by @siosm 2026-01-26T17:48:30Z

Last edited by @siosm 2026-01-26T17:48:30Z

2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

Can you provide instructions for how one can check if they are using an AppImage that relies on the Type 1 runtime? I have several third-party applications that I use and I’d like to know ahead of time if they’ll cease functioning properly.

4

You can get the runtime for an AppImage with the --appimage-version command line option according to AppImageKit#command-line-arguments.

With the Krita AppImage, I got:

$ ./krita-5.2.14-x86_64.AppImage --appimage-version
AppImage runtime version: https://github.com/AppImage/type2-runtime/commit/2df896e

I don’t know where to find old AppImages to check.

(Thanks for the idea. I’ve updated the wiki & post with the instructions).

5

Fully on-board with this.

6

This change proposal has now been submitted to FESCo with ticket #3554 for voting.

To find out more, please visit our Changes Policy documentation.

7

Side note: This will remove fuse-encfs on KDE variants: https://pagure.io/fedora-kde/SIG/issue/490.

Plasma Vault has support for creating vaults using EncFS. While that support still exists in Plasma Vaults, EncFS has been EOL for a while and hasn’t been offered as an option for users to choose from for new Vaults for a while: Don't let people create new EncFS vaults (!57) · Merge requests · Plasma / Plasma Vault · GitLab.

I’ll add that to the release notes.

Edit: Users can get access to their Vaults back after the update by layering the packages again as needed.

8

Unfortunately this doesn’t seem to be a universal way to check:

❯ for f in *.AppImage; do echo "$f:"; "./$f" --appimage-version; done 
Feishin-linux-x86_64.AppImage:
Version: effcebc
fflogs.AppImage:
Version: effcebc
FontBase.AppImage:
AppImage runtime version: https://github.com/AppImage/type2-runtime/commit/5e7217b
Joplin.AppImage:
Version: effcebc
LosslessCut-linux-x86_64_9b32cdfd7fe2c6219a8f8c88d0a2e23f.AppImage:
Version: effcebc
LosslessCut-linux-x86_64.AppImage:
Version: effcebc
lrcget.AppImage:
Version: 5735cc5
md.obsidian.Obsidian.AppImage:
Version: effcebc
MediaElch.AppImage:
Version: 5735cc5

I’m not sure what effcebc and 5735cc5 refers to. Obviously it’s a commit hash, but no such commit exists on the linked repo:
https://github.com/AppImage/type2-runtime/commit/effcebc

https://github.com/AppImage/type2-runtime/commit/5735cc5

At first glance the effcebc AppImages are all Electron based, so that might be related. But the two 5735cc5 AppImages are not related at all. lrcget is Tauri based, and MediaElch is a Qt application (and both releases are quite far apart too for that matter).

I’m not sure if there is a better way to check.

The reason I bring this up is because on the Feishin Discord we occasionally get CachyOS users, where apparently fuse2 is not installed by default, and they aren’t able to run the AppImage (though unfortunately none of them seemingly ever reply with terminal output
)

Either way, without being able to check, my assumption is that it is fuse related.

If that is the case, then “ask upstream to update them to the newer AppImage runtime” might not actually be viable. For a lot of projects they don’t use AppImagetool directly, which is in line with the intention of the tool:

in most cases you will be better off using one of the higher-level tools instead of using appimagetool directly.

They in turn rely on other upstream projects that do the actual package building and have no control over the runtime used.
So if it is the case that the runtime is the issue, then removing fuse2 would be quite an issue for users (especially given how ubiquitous Electron applications are), and I’m not sure the benefit of a “smaller image” is worth it considering the comparatively tiny size of the library:

❯ sudo dnf remove fuse fuse-libs
Package                                 Arch       Version                                 Repository               Size
Removing:
 fuse                                   x86_64     2.9.9-23.fc42                           fedora              222.5 KiB
 fuse-libs                              x86_64     2.9.9-23.fc42                           fedora              305.1 KiB
Removing dependent packages:
 cryfs                                  x86_64     0.11.3-12.fc42                          fedora                4.0 MiB
 dracut-live                            x86_64     107-4.fc42                              <unknown>            40.5 KiB
 fuse-encfs                             x86_64     1.9.5-24.fc42                           fedora                1.6 MiB
Removing unused dependencies:
 boost-program-options                  x86_64     1.83.0-12.fc42                          fedora              276.7 KiB

Transaction Summary:
 Removing:           6 packages

After this operation, 6 MiB will be freed (install 0 B, remove 6 MiB).

After the image compression this is essentially a rounding error.

9

I found effcebc & 5735cc5 in the AppImage/AppImageKit repo. I don’t know if this means that the apps are type-1 only.

I did mention that first in the benefits section, but really the problem is that FUSE2 is unmaintained so we can not keep it indefinitely in the image and expose all users to potential bugs/vulnerabilities.

If applications haven’t been updated since 2019 (date of the first commit mentioned), I don’t think waiting another release will help.

I took at quick look at some apps from your list:

1 Like
10

Hm not sure either. But given that type2 has its own repo, I would assume so.

Sure I understand that, however what I’m getting at is that the applications listed above (minus MediaElch) are maintained. In fact some of them weren’t even around in 2019.

I agree that keeping unmaintained packages around is not a good idea, however there’s 2 problems with that:

  1. They are still in the repos so it’s sort of hard to communicate to users why an unmaintained package is OK in the repos, but not ready to be used
  2. Fuse2 is (as far as I know anyway) still included in non-atomic flavors (feel free to correct me), which would also raise the question of “why is it OK in one but not the other”

Putting the issue on Fedora’s end aside, the problem is still that application maintainers have no control over the runtime in use. They use electron-builder, Tauri, linuxdeploy (in the case of MediaElch) or whatever else, which seemingly build on these old commits.

Obviously I’m not suggesting that Fedora is responsible for maintaining these toolkits, I’m just saying we need to be mindful that we’re breaking user and developer usecases that neither of them have any control over and they might not even know why.

So it might be a good idea to contact at least the “big” toolkits about this.

That being said, I haven’t tested whether fuse2 is actually the issue with Feishin for example.

11

They are still in the repos because some packages depend on them. Packages unmaintained upstream can remain in the repos as long as there is a maintainer in Fedora.

First, I want to defend the option for each variant in Fedora to decide what they want included or not. We are allowed to take different decisions on package inclusion for the Atomic variants and we don’t have to match 1:1 what is included in another Fedora Edition.

With that being said, the main difference is that package removal is more costly on Atomic variants than on non-Atomic ones. It’s easier to ask a few Atomic Desktops users to overlay a specific package when they encounter an issue with an AppImage using an older runtime (and ask them to report that upstream) than to tell everyone that do not use AppImages to pay the cost of removing a package.

If you read Drop fuse (version 2) from all Atomic Desktops images (#50) · Issues · Fedora / Fedora Atomic Desktops / SIG Issue Tracker · GitLab, this whole discussion started because FUSE2 was dropped from Silverblue because nothing depended on it anymore.

For non-Atomic variants, FUSE2 is only included in Workstation via the dependency on dracut-live, which is only here for the Live ISO. I have not checked if it’s removed on installation.

In KDE Plasma, it’s there as a dependency of fuse-encfs & cryfs. I mentioned fuse-encfs in F44 Change Proposal: Atomic Desktops: Drop FUSE 2 libraries [SelfContained] - #7 by siosm and it looks like I missed cryfs. fuse-encfs in unmaintained and cryfs is aware of the issue: please add support for fuse 3 · Issue #419 · cryfs/cryfs · GitHub.

Finally, I had missed that as well, but Plasma Vault also does not let users create new vaults with cryfs either: Only allow gocryptfs for new vaults (ba292cce) · Commits · Plasma / Plasma Vault · GitLab.

So in the end we don’t really have a good reason to keep FUSE2 included in the non-Atomic variants as well so it may be removed from those Editions as well in the future.

1 Like
12

I can confirm that it’s not (as of F43).

1 Like
13

Thanks for the explanation.

One thing I want to say though in case it came across wrong, I’m not against the removal in principal, I’m just concerned about a removal right now when there are potentially a lot of applications affected.

That being said, I haven’t gotten around to testing whether fuse2 is actually the issue with Feishin (or any other appimage on that list for that matter).

14

Do you mean that it’s not removed or not keep installed?

15

Not removed; it stays on the system. I always have to remove it manually.

1 Like
16

OK, but when should we removed it then? If nothing changed since 2019, I don’t think things will until users of AppImages start complaining to their upstream that their AppImages are using an older runtime. We can not carry legacy software forever.

17

Incidentally, the author of AppImage has been on a personal crusade against Wayland for years:

Make of that what you will.

18

I agree with you on that one, the question is whether the upstreams are even aware of this (which I haven’t checked), but also why I said this:

I don’t think I ever suggested that either.

Regardless, I did some digging.

From some past dealings with Tauri I know that they don’t package the AppImage themselves, and don’t use AppImageTool directly either. They rely on another upstream project, namely linuxdeploy and its AppImage plugin.

Searching the Tauri repo actually brings up the Release notes including this:

Enhancements

  • 8b465a12b (#13913 by @FabianLars) The bundler now pulls the latest AppImage linuxdeploy plugin instead of using the built-in one. This should remove the libfuse requirement.

For reference this was v2.8.0 released in August 2025.

So after projects cycle through their dependency updates I guess this should sort itself out.

Which leaves Electron, arguably the larger userbase between the two.

I’m looking at electron-builder specifically since I know that’s what Feishin uses, but I think there are alternate NPM packages for the same task, I can’t check them all. Anyway, for this one a quick issue search lands on this:

The issue is originally from Nov 2024, but recent comments indicate there is work being done towards finally using the newer runtime.

There is also a Draft PR opened 2 days ago for this purpose:

If we’re assuming this isn’t going to take forever to merge, this should be released within the next couple of weeks/months.

Electron and electron-builder updates tend to trickle down to projects fairly quickly due to dependabot for NPM, so realistically it shouldn’t take too long for maintained projects to hit them.

With all that said, maybe this could be put off for one more release? By that time affected projects should have a realistic migration path (i.e. upgrade electron-builder or Tauri), assuming this PR doesn’t take forever.

1 Like
19

This change has been approved by FESCo and will be included in Fedora Linux 44.
To find out more about how our changes policy works, please visit our docs site.

FESCo Issue: Making sure you're not a bot!

1 Like