Anything that uses fuse can use fuse3.
Personally I use sshfs and mtpfs
Since fuse 2 and 3 can get along with each other on the same system and fuse 2 remains the default, it will be transparent to the end users and it allows people (like me) who'd like to switch to fuse 3 to do it smoothly.
Packages were built following the recommendations of the developers.
This being said, I don't really understand why fuse 3 doesn't just supersede fuse 2. Of course a few new options were dropped and some others were added but that's the same with any applications.
@ikey : I have done a couple of tests...
I could rebuild and use gvfs against fuse3 without any problem
I haven't been able to rebuild sshfs even with basic patching. Since fuse & sshfs are developed by the same team, I don't think it's worth digging this further.
As sshfs is a blocker for now, I haven't checked the other reverse dependencies.
For what it's worth, we attempted to upgrade everything to FUSE 3 in Mageia Cauldron, and that ended pretty badly. We've since reverted that and rolled back to FUSE 2 by default and shipping FUSE 3 as a separate parallel-installable package.
Rolling everything to fuse3 is crazy since very few apps are compliant so far.
Fuse3 was designed to co-exists with Fuse2 which will certainly not encourage a fast adoption.
sshfs is the main (and only?) reason for me to consider adding fuse3 in the repository.
I didn't realize this when I introduced the request. Now I have a different view, I would rather update fuse & sshfs to the latest version of the branch 2.x (see D770 and D771) but before pushing for an update (and having to rebuild all the fuse stuffs), I need to understand why libgthreadis dropped in my sshfs update. This is not normal.
BTW, i didn't mean to reopen this one myself, i clicked "Add Action" and forgot i did that while posting the comment.
I guess these things are done by core team only, but i'll leave it like this for now, feel free to overrule me.
So, let me write my findings here.
I built fuse 3 package and copied resulting .eopkg files in local repo.
I tried to rebuild all the packages that depend on fuse (fuse2) with fuse 3 instead, using make local and pkgconfig(fuse3).
The problem is that almost none of the packages that use fuse2 are compatible with fuse3, and this is to blame developers of those software.
Most of them are reluctant to port their code to work with fuse3, so they just leave it as it is.
Exception are two packages (not counting fuse-overlayfs): gvfs (since version 1.41.1) and sshfs 3.x (we still use sshfs 2.x because versions 3.x depend on fuse 3).
Fortunately for us, fuse3 can co-exist with fuse2 on the same system.
Developers of libfuse even wrote this in fuse 3.0.0 release notes: https://github.com/libfuse/libfuse/releases/tag/fuse-3.0.0
libfuse 3 is designed to be co-installable with libfuse 2. However, some files will be installed by both libfuse 2 and libfuse 3 (e.g. /etc/fuse.conf, the udev and init scripts, and the
mount.fuse(8) manpage). These files should be taken from libfuse 3. The format/content is guaranteed to remain backwards compatible with libfuse 2.
We recommend to ship libfuse2 and libfuse3 in three separate packages: a libfuse-common package that contains files shared by libfuse 2+3 (taken from the libfuse3 tarball), and libfuse2 and
libfuse3 packages that contain the shared library and helper programs for the respective version.
We can solve this by leaving fuse2 in it's separate package, removing those common files from package and making it depend on fuse-common which will be built from new package called fuse3.
fuse3 package.yml can contain patterns to pack it's common files in separate eopkg sub-package, thus producing packages fuse3, fuse3-devel and fuse-common.
I would like to reopen this task. I am heavily using podman for developement purposes and having fuse-overlayfs (T8408) would be very nice to improve disk usage.
I would also package and maintain fuse3 and fuse-overlayfs. I think the solution of chax (3 packages fuse2, fuse3 and fuse-common) would be a suitable solution.
I'm not approving any changes to fuse without guarantees that nothing gets broken. Period. It's too core to certain low-level userspace components like gvfs and userspace filesystem drivers to treat lightly. As for package naming, in situations like this a new package would be created for the legacy release (fuse2), the existing fuse package would be upgraded, and the fuse-common package would be patterned out of fuse so that fuse2 is more easily deprecated. The devs seem to have gotten that part right at least.