Please consider to offer fusermount backward compatibility

[probonopd]

Please consider to offer backward compatibility guarantees with regard to fusermount.

This would be very beneficial for the AppImage file format, which relies on FUSE heavily.
An AppImage is essentially a self-mounting disk image that runs the application contained therein. In order to be self-mounting, it contains libfuse, which in turn needs fusermount. But since fusermount is setuid root, it cannot be shipped inside the AppImage but rather the version from the operating system needs to be used.

We need to establish a way to make it so that AppImages built today will continue to run on future operating systems.

For decades, there used to be the fusermount binary on virtually every desktop distributions. However, many distributions are now shipping fusermount3 by default, and are no longer shipping fusermount on the $PATH by default. One day they might ship fusermount4,... fusermountN.

It would be very valuable if

• There would be explicit backward compatibility guarantee, e.g., "all future versions of fusermountN will be able to work with all previous versions of libfuse
• A constant, never-changing name for fusermount could be put on the $PATH, so that we don't have to try to look up fusermount under different names such as fusermount,fusermount3, fusermount4,... fusermountN

Creating backward compatibility is much easier for the upstream project (FUSE) than for downstream projects (e.g., AppImage) to try to create forward compatibility with future FUSE versions (which is essentially "engineering by hope"), with trickery such as

hanwen/go-fuse@934a183

Thank you very much for your consideration!

Reference:

• fusermount, fusermount3,... fusermountN compatibility guarantees?  #670