fuse3.md

Learnings from the FUSE 3 breakage

Major Linux distributions as of today are unpredictable as targets for independent software vendors trying to publish applications because they are lacking guarantees regarding what software is part of the software stack supported by the operating system vendor.

Reasonably policies would be needed to improve the situation and give outside software developers targeting Linux distributions enough lead time to anticipate changes.

Example

https://github.com/libfuse/libfuse/releases/tag/fuse-3.0.0 was released in December 2016. Now, 5 years later, we are seeing this new major version as a problem, which goes like this:

• libfuse 3.0.0 was "designed to be co-installable with libfuse 2" (source)
• Initially, distributions happily shipped libfuse3 and libfuse2 in their repository
• Until recently, distributions shipped libfuse2 in their default installation and on Live ISOs because other packages depended on it ((source)[https://bugs.launchpad.net/ubuntu/+source/fuse3/+bug/1934510])
• Lately, distributions engaged in distribution-internal discussions (e.g., Ubuntu in in July 2021) to port everything that required libfuse2 to libfuse3 (source)
• However, no one discussed this with projects outside of distributions who are highly dependent on libfuse2 being available on all systems, like AppImage. How is a project that is not part of a Linux distribution supposed to know that a discussion buried away under a title like "[MIR] fuse3 as a dependency of qemu 6.0 and GNOME apps" means that soon libfuse2 that has been part of every Linux desktop for more than a decade will soon be no longer there by default?
• As soon as they changed their own packages to no longer depend on libfuse2, they now no longer want to support it because it has not been actively maintained by upstream anymore.
• In Ubuntu 21.10 (October 2021) libfuse3 is in universe (=unsupported) and libfuse2 is in main (=supported) (source) but just one version later in Ubuntu 22.04 (April 2022), libfuse3 is destined to be in main (=supported) and libfuse2 is in universe (=unsupported) (source), making both versions of libfuse supported in exactly 0 versions of Ubuntu. Even worse, both versions of libfuse are supported in exactly 0 LTS releases of Ubuntu. Not even one. How valuable is it to have libfuse 3.0.0 "designed to be co-installable with libfuse 2" when distributions don't want to support more than one version?
• As a result, all existing applications (including all AppImages made so far) that rely on the existence of libfuse2 break
• Meanwhile, libfuse is already at version 3.10.5 and no one knows how long it will be until an incompatible version 4.0.0 will appear, at which point the cycle of suffering will repeat itself?
• Does anyone care about preserving the possibility to run old versions of applications on new distributions?

Takeaways

• It would be helpful if upstream authors of core system libraries did everything possible to avoid breaking changes (major versions) at all cost, as they create a huge pain and extra work for everyone even half a decade later
• It would be very useful if Linux Foundation would define the Linux Standards Base Desktop again and lobby for distributions to comply to it
• Also it would be very helpful if distributions made guarantees not to remove core system libraries nor to replace them with breaking new major versions without announcing the date of the switch a couple of years in advance, so that everyone has enough time to adopt
• The mindset that only software that is constantly changed should be supported is adding plenty of work for everyone all the time. We should rethink our mindset. Isn't software that needs no further changes the most reliable and best software, after all?
• There should be a policy that if a library in Ubuntu main gets upgraded to a new major version, the old major version would need to stay in main for at least one (1) LTS release of Ubuntu.
• Also, there should be a policy that no library can be removed from Ubuntu main without the library being explicitly marked as deprecated in package lists at least for one full LTS cycle.
• Ubuntu just being used as an example here. Such policies would make distributions much more reliable and useful as a target for outside developers than they are today.

One can dream.