Bug#927221: gvfs-fuse version-specific depend on fuse (>= 2.8.4) blocks trans to fuse3

[Simon McVittie]

On Tue, 16 Apr 2019 at 07:27:51 -0500, Ron Lovell wrote:
> Is the current dependency of gvfs-fuse on fuse (>=2.8.4) really
> necessary? Would a dep on simply 'fuse' suffice?

Does fuse3 provide everything that's needed to mount and unmount older
FUSE filesystems that are still linked to libfuse2, like gvfs-fuse?

If it does, then gvfs-fuse can depend on fuse (>= 2.8.4) | fuse3, or
just depend on plain "fuse" which is provided by fuse3 (since 2.8.4 is
older than oldstable anyway); or fuse3 could have a versioned
Provides: fuse (= ${binary:Version}) which would make gvfs-fuse and
packages like it (archivemount is another example) work without changes.

If fuse3 doesn't provide everything necessary for FUSE 2 filesystems,
then its Provides: fuse is misleading, and we'd need to look into which
specific facilities are actually needed by packages like gvfs-fuse and
archivemount.

It looks as though fuse3 has dropped the ulockmgr_server executable. I
don't know whether gvfs-fuse actually needs this, though? What does it
do, and is there a straightforward way we can know whether a particular
FUSE filesystem needs it?

Since it seems you're already running GNOME, please could you try a
locally-patched gvfs-fuse package that changes the dependency to what
you propose? If you use a GNOME app like the Nautilus file manager
("Files") to navigate to something supported by gvfs, like a Windows
Networking or Samba share (SMB/CIFS) via "smb://" or an Android phone
that uses MTP, you should find that you get an instance of gvfsd-fuse
mounted on $XDG_RUNTIME_DIR/gvfs.

If you don't have a Windows/Samba file-share nearby, navigating to
"smb://WORKGROUP" in Nautilus should be enough to trigger mounting of
$XDG_RUNTIME_DIR/gvfs (but it will be empty).

> Or dep on libfuse2?

This would not be sufficient. FUSE filesystems need the /sbin/mount.fuse
mount helper, which is provided by the fuse or fuse3 packages.

> I agree this sounds more like a wishlist than important issue. But
> the transition to fuse3 and sshfs 3+ seems to have hit a logjam,
> and I'm just trying to help move things along.

That doesn't require 'important' severity: we can solve wishlist bugs
with simple fixes a lot more easily than we can solve important bugs
that have no clear solution.

> It would be great if we could have sshfs 3.5.1+ in
> Buster, or if not, at least in Sid soon.

buster has been in hard freeze for a month, so it's much too late to
have sshfs 3 in buster. If there's a solution to this bug (and bugs
like it in other FUSE filesystems) that is not too intrusive and can
be fast-tracked into buster, then you might be able to have sshfs 3 in
buster-backports shortly after the release.

    smcv