fuse-t: init at 1.0.42

[Enzime]

• Added fuse-t, fuse-t.binaryDistribution and fuse-t.stubs
• Use fuse-t instead of macFUSE for sshfs-fuse

You can test this PR with:

nix run github:numtide/nixpkgs-unfree#fuse-t --override-input nixpkgs github:Enzime/nixpkgs/fuse-t -- user@host:/path /mount/point 

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[midchildan]

I'm a bit concerned about including the unfree NFS server. I believe Hydra doesn't build unfreeRedistributable packages. Wouldn't this cause more popular packages to be dropped from the Darwin binary cache as more packages switch to FUSE-T?

#83884

[emilazy]

AIUI packages will only link to the stubs, which are FOSS (as they have to be, because FUSE is LGPL).

(Will try to find the time to review the rest of this soon.)

[midchildan]

It appears that the fuse-t package isn't a stub, but rather a mixture of a source-built libfuse and the unfree NFS server. So in this case, I believe sshfs-fuse will be dropped from the binary cache.

[midchildan]

What's the purpose of creating a TBD stub from a source-built package? I'm confused because I recognize TBD stubs as substitutes for actual dylib files, yet the built dylib is included in this package.

[Enzime]

I just copied it from the macFUSE derivation, I didn't actually know what they were for

[midchildan]

I see. So here's the background. macFUSE consists of a kernel extension, preference pane, and the userspace libfuse library. This created a few challenges.

1. Everything except libfuse is unfree which disqualifies it from being the on binary cache
2. Preference panes and kernel extensions can't be installed with Nix
3. libfuse works closely with the kernel extension, so version mismatches could break things

So I took the approach of making users install macFUSE outside of Nix and have packages link to the out-of-store libfuse. To achieve this, the macfuse-stub package creates a stub of libfuse using the actual macFUSE release so that compilers can link to it without it being actually present in /usr/local/lib.

With FUSE-T, problem No. 1 remains. And if we drop the NFS server but build libfuse from source, we'll have problem No. 3 as well. So I think the FUSE-T package should take the same approach to avoid these problems.

[Enzime]

In the case of FUSE-T, the location for the NFS server is compiled in a header https://github.com/NixOS/nixpkgs/pull/348804/files#diff-542ad4d614512f9a215eaba4a723df42cc4a1fdc6f1d339f73a35818a50b043e but can be overridden with the environment variable FUSE_NFSSRV_PATH

So we could change it from directly pointing to the unfree NFS server to /run/current-system/sw/bin and then nix-darwin users can install the unfree NFS server using environment.systemPackages

In addition we could create wrappers (living under different attributes, so the downstream packages still get cached) that set FUSE_NFSSRV_PATH so that users can still use the packages from Nixpkgs without needing to manually install the unfree NFS server

[emilazy]

I don’t suppose there’s any chance of using the same stubs for both macFUSE and FUSE-T?

[midchildan]

I don't think so. FUSE-T changed the filename to libfuse-t.dylib for one thing.

[midchildan]

So we could change it from directly pointing to the unfree NFS server to /run/current-system/sw/bin and then nix-darwin users can install the unfree NFS server using environment.systemPackages

For maximum compatibility, I guess we can use the header as is and introduce a nix-darwin module that makes FUSE_NFSSRV_PATH point to the Nix store. This would allow both Nix and non-Nix applications to use FUSE-T.

It should be noted though, that some applications use libraries that bypass libfuse and talk to the NFS server directly. Those aren't guaranteed to respect FUSE_NFSSRV_PATH. This is likely not an exhaustive list, but I found one case where the path is hardcoded.

https://grep.app/search?q=FUSE_NFSSRV_PATH

There are also cases like cgofuse, which uses dlopen() to load libfuse from a hardcoded path.

https://github.com/winfsp/cgofuse/blob/f87f5db493b56c5f4ebe482a1b7d02c7e5d572fa/fuse/host_cgo.go#L176

In addition we could create wrappers (living under different attributes, so the downstream packages still get cached) that set FUSE_NFSSRV_PATH so that users can still use the packages from Nixpkgs without needing to manually install the unfree NFS server

You mean like steam-run? That sounds nice, though I think we'd need to check that two different instances of the NFS server can run at the same time. Nix being Nix, users may have multiple FUSE-T NFS servers in their Nix store.

From what I've seen in FUSE-T libfuse's code, it does appear to be okay. libfuse creates a socket pair using socketpair(), forks and launches the NFS server, and uses the created socket to communicate with the newly launched server. It's probably a good idea to check though, because we don't know exactly what happens in the NFS server.