Skip to content

fuse3: init at 3.1.1#28409

Closed
primeos wants to merge 0 commit intoNixOS:masterfrom
primeos:fuse3
Closed

fuse3: init at 3.1.1#28409
primeos wants to merge 0 commit intoNixOS:masterfrom
primeos:fuse3

Conversation

@primeos
Copy link
Member

@primeos primeos commented Aug 19, 2017 •
edited
Loading

Motivation for this change

Add fuse3 (libfuse 3.x). Any help is welcome 😄 - I'm not that familiar with libfuse...

Note to Packagers

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.

TODO:

  • Install libfuse 2 and 3 by default
  • /etc/fuse.conf from libfuse 3
    • We currently don't provide /etc/fuse.conf
  • udev and init scripts from libfuse 3
    • udev rules from libfuse 3
    • Init scripts not included
  • mount.fuse man page from libfuse 3 (TODO: define priority)
  • Add libfuse-common like recommended (added but not really used as own package)?
  • Merge the package definitions for 2.x and 3.x (e.g. common.nix, 2.nix and 3.nix)?
  • Wait for some reviews (some things might be wrong/missing)

@mornfall would you like to maintain libfuse3 as well?

Things done
  • Tested using sandboxing
    (nix.useSandbox on NixOS,
    or option build-use-sandbox in nix.conf
    on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • Linux
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

@mention-bot
Copy link

mention-bot commented Aug 19, 2017

@primeos, thanks for your PR! By analyzing the history of the files in this pull request, we identified @ixmatus, @globin and @abbradar to be potential reviewers.

@primeos primeos force-pushed the fuse3 branch 2 times, most recently from 2628298 to 91b1c17 Compare August 19, 2017 17:39
@Mic92
Copy link
Member

Mic92 commented Aug 19, 2017 •
edited
Loading

Do you know a file system already using fuse3 (for testing)?

@primeos
Copy link
Member Author

primeos commented Aug 19, 2017

@Mic92 Yes, I've tested it with sshfs-fuse (version 3.2.0). But I just realized that it might be the only one so far...

I'll add that commit to this PR.

Mic92
Mic92 approved these changes Aug 26, 2017
View reviewed changes
Copy link
Member

@Mic92 Mic92 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can use the old sshfs as well as the new version in parallel.

@primeos
Copy link
Member Author

primeos commented Aug 29, 2017

@Mic92 Sorry for my late reply & thanks for testing it. If you don't mind I'll resolve the last TODOs (might have to wait until next week) and merge it after the branch off, since it isn't that important ATM and sshfs 2.10 is probably better for 17.09 anyway.

I can use the old sshfs as well as the new version in parallel.

I would've replaced sshfs 2.x with 3.x, because of the following note from the 2.10 release:

This is a maintenance release of the SSHFS 2.x line.
Please use a SSHFS 3.x release if you can!

Is that ok or should I keep sshfs 2.x and add a new attribute for 3.x (sshfs3)?

@fpletz
Copy link
Member

fpletz commented Aug 30, 2017

Seems fine to me. Thanks!

@fpletz fpletz added this to the 18.03 milestone Aug 30, 2017
@fpletz fpletz added 2.status: work-in-progress 8.has: package (new) This PR adds a new package 8.has: package (update) This PR updates a package to a newer version labels Aug 30, 2017
@primeos
Copy link
Member Author

primeos commented Sep 11, 2017 •
edited
Loading

I've just updated the PR (sorry for the delay, got a cold...).

Now all files provided by libfuse 2 and 3 should come from libfuse 3 as recommended (just in case). I've also added fuse-common (might be useful for udev) but I couldn't figure out a good way to use it for fuse and fuse3 (since the latter would obviously cause an infinite recursion or I would have to use another approach with other disadvantages). Imho replacing the shared files from libfuse 2 with the ones from libfuse 3 / fuse-common and using priorities to avoid collision warnings was the best idea, but it isn't perfect... - Any suggestions to improve this are welcome 😄

But at least this way should be backwards compatible. If it looks ok I'd run some final tests and merge it.

@primeos primeos closed this Sep 21, 2017
primeos added a commit to primeos/nixpkgs that referenced this pull request Sep 21, 2017
@primeos
fuse3: init at 3.1.1
351f5fc 
This includes fuse-common (fusePackages.fuse_3.common) as recommended by
upstream. But while fuse(2) and fuse3 would normally depend on
fuse-common we can't do that in nixpkgs while fuse-common is just
another output from the fuse3 multiple-output derivation (i.e. this
would result in a circular dependency). To avoid building fuse3 twice I
decided it would be best to copy the shared files (i.e. the ones
provided by fuse(2) and fuse3) from fuse-common to fuse (version 2) and
avoid collision warnings by defining priorities. Now it should be
possible to install an arbitrary combination of "fuse", "fuse3", and
"fuse-common" without getting any collision warnings. The end result
should be the same and all changes should be backwards compatible
(assuming that mount.fuse from fuse3 is backwards compatible as stated
by upstream [0] - if not this might break some /etc/fstab definitions
but that should be very unlikely).

My tests with sshfs (version 2 and 3) didn't show any problems.

See NixOS#28409 for some additional information.

[0]: https://github.com/libfuse/libfuse/releases/tag/fuse-3.0.0
globin pushed a commit that referenced this pull request Sep 22, 2017
@primeos @globin
fuse3: init at 3.1.1
586db45 
This includes fuse-common (fusePackages.fuse_3.common) as recommended by
upstream. But while fuse(2) and fuse3 would normally depend on
fuse-common we can't do that in nixpkgs while fuse-common is just
another output from the fuse3 multiple-output derivation (i.e. this
would result in a circular dependency). To avoid building fuse3 twice I
decided it would be best to copy the shared files (i.e. the ones
provided by fuse(2) and fuse3) from fuse-common to fuse (version 2) and
avoid collision warnings by defining priorities. Now it should be
possible to install an arbitrary combination of "fuse", "fuse3", and
"fuse-common" without getting any collision warnings. The end result
should be the same and all changes should be backwards compatible
(assuming that mount.fuse from fuse3 is backwards compatible as stated
by upstream [0] - if not this might break some /etc/fstab definitions
but that should be very unlikely).

My tests with sshfs (version 2 and 3) didn't show any problems.

See #28409 for some additional information.

[0]: https://github.com/libfuse/libfuse/releases/tag/fuse-3.0.0

(cherry picked from commit 351f5fc)
@oxalica oxalica mentioned this pull request Aug 27, 2025
Merged
13 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@Mic92 Mic92 Mic92 approved these changes

Assignees

No one assigned

Labels

8.has: package (new) This PR adds a new package 8.has: package (update) This PR updates a package to a newer version

Projects

None yet

Milestone

18.03

Development

Successfully merging this pull request may close these issues.

4 participants

@primeos @mention-bot @Mic92 @fpletz