nixpkgs/pkgs/os-specific/linux/fuse/default.nix

{ callPackage, util-linux }:

let
  mkFuse = args: callPackage (import ./common.nix args) {
    inherit util-linux;
  };
in {
  fuse_2 = mkFuse {
    version = "2.9.9";
    hash = "sha256-dgjM6M7xk5MHi9xPyCyvF0vq0KM8UCsEYBcMhkrdvfs=";
  };

  fuse_3 = mkFuse {
    version = "3.16.2";
    hash = "sha256-QO9s+IkR0rkqIYNqt2IYST6AVBkCr56jcuuz5nKJuA4=";
  };
}
utillinux: rename to util-linux 2020-11-24 15:29:28 +00:00			`{ callPackage, util-linux }:`
* Doh! svn path=/nixpkgs/trunk/; revision=4183 2005-11-01 12:11:12 +00:00
fuse3: init at 3.1.1 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 2017-08-19 16:50:53 +00:00			`let`
			`mkFuse = args: callPackage (import ./common.nix args) {`
utillinux: rename to util-linux 2020-11-24 15:29:28 +00:00			`inherit util-linux;`
* Doh! svn path=/nixpkgs/trunk/; revision=4183 2005-11-01 12:11:12 +00:00			`};`
fuse3: init at 3.1.1 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 2017-08-19 16:50:53 +00:00			`in {`
			`fuse_2 = mkFuse {`
fuse: 2.9.8 -> 2.9.9 2019-01-04 17:35:40 +00:00			`version = "2.9.9";`
fuse3: 3.11.0 -> 3.16.1 https://github.com/libfuse/libfuse/blob/fuse-3.16.1/ChangeLog.rst#libfuse-3161-2023-08-08 One change can be expected to break some setups: - Unsupported mount options are no longer silently accepted [1] For example, sshfs built against the present libfuse 3.11.0, `$ sshfs 127.0.0.1:/home/test/testdir /home/test/sshfs_mnt -o atime` terminates successfully (with the mount point established), while when built against 3.16.1, it outputs the error message `fuse: unknown option(s): `-o atime'` and terminates with exit status 1. 2023-08-26 16:42:37 +00:00			`hash = "sha256-dgjM6M7xk5MHi9xPyCyvF0vq0KM8UCsEYBcMhkrdvfs=";`
* Latest FUSE, sshfs. svn path=/nixpkgs/trunk/; revision=9964 2007-12-24 13:27:07 +00:00			`};`
fuse3: init at 3.1.1 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 2017-08-19 16:50:53 +00:00
			`fuse_3 = mkFuse {`
fuse3: 3.16.1 -> 3.16.2 https://github.com/libfuse/libfuse/blob/fuse-3.16.2/ChangeLog.rst#libfuse-3162-2023-10-10 https://github.com/libfuse/libfuse/compare/fuse-3.16.1...fuse-3.16.2 2023-10-14 15:06:38 +00:00			`version = "3.16.2";`
			`hash = "sha256-QO9s+IkR0rkqIYNqt2IYST6AVBkCr56jcuuz5nKJuA4=";`
fuse3: init at 3.1.1 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 2017-08-19 16:50:53 +00:00			`};`
* Doh! svn path=/nixpkgs/trunk/; revision=4183 2005-11-01 12:11:12 +00:00			`}`