Make the macfuse port play well with other macfuse installations

[registrera@…]

The kernel extension of macfuse is installed outside the "isolated" environment of macports and conflicts with other installations of the same kernel extension. Since the version provided by macfuse is lagging a few versions behind it is becoming difficult to use the macfuse-dependent ports simultaneously with non-port fuse-filesystems.

The ​recommended way to keep Macfuse up to date is through the official automatic updater. But at least the mp3fs-port doesn't work if other applications use the automatic updater and replaces the kernel extension.

Maybe it would be possible to include the automatic updater in the port? Or maybe it would be better to just wrap the official installer with a port and link to the headers and lib-files for dependent ports to use (​suggested a long time ago by a Macfuse developer)?

I have temporarily solved my own problems (getting mp3fs-port to work with official Macfuse-install) by symlinking /opt/local/include/fuse to /usr/local/include/fuse (created by official installer) and each libfuse* in /opt/local/lib to the corresponding file in /usr/local/lib

I'm not capable of determining which is the best approach, or if there are any side effects of my own attempt to solve this. All I can say is that it would be great if "it just worked".

Regards

/Daniel

[registrera@…]

Sorry for my confusing links. The changeset links where supposed to be flags for my footnotes.

[mf2k (Frank Schima)]

I incorporated the links into the text.

[registrera@…]

Thanks for fixing my unintended markup ...

But the second link is not to the official installer, but to the message with the suggestion to wrap it with the macport. The whole phrase "wrap the official installer" or maybe rather some part of the following parenthesis would be better as the link text.

[mf2k (Frank Schima)]

OK, I moved the second link to hopefully a more appropriate place.

[ryandesign (Ryan Carsten Schmidt)]

It's not appropriate for software installed with MacPorts to have its own automatic updater. MacPorts is the method by which software installed with MacPorts should be updated. If the port is outdated, its maintainer should update it.

[registrera@…]

Replying to ryandesign@…:

It's not appropriate for software installed with MacPorts to have its own automatic updater. MacPorts is the method by which software installed with MacPorts should be updated. If the port is outdated, its maintainer should update it.

Ok. That makes sense for libraries that can be relocated and isolated under the /opt/local-prefix. As this comes out, it's just a policy that can't be enforced. Other applications will update MacFuse through the official and endorsed automatic updater regardless of what is appropriate to us. It would be great if the port always was up to date, but it won't happen.

Sticking to this policy will make it difficult to use and rely on any port-libraries that depend on MacFuse.

[macports@…]

Cc Me!

[abh (Ask Bjørn Hansen)]

Cc Me!

[drkp (Dan Ports)]

Cc Me!

[drkp (Dan Ports)]

I'm not sure what to about this one. Normally I would just agree with Ryan that

It's not appropriate for software installed with MacPorts to have its own automatic updater. MacPorts is the method by which software installed with MacPorts should be updated. If the port is outdated, its maintainer should update it.

...and so we should just expect people not to install MacFUSE outside of MacPorts. (Indeed, it's best by far if they don't.) For most ports I'd just leave it at that.

I do understand why people are suggesting macfuse might be an exceptional case, because it installs files outside of $prefix (the kernel extension and a framework in /Library/Frameworks). And, besides the autoupdate mechanism, there are various programs that ship a copy of MacFUSE (VMware Fusion comes to mind).

I'm not sure what we can do about it, if anything's even possible. It doesn't really make sense to have multiple installations, since they're going to conflict on the kernel extension if nothing else. And any user-space file system daemons need to be built against the right version of the fuse library.

The approach the developers seem to recommend is to always have the latest version installed to avoid conflicts. It probably doesn't matter so much whether this is achieved through autoupdate or through keeping the port up to date. This ticket was created at a time when the macfuse port significantly lagged behind upstream (because 2.0 introduced a different build system). In that world, I could easily see problems if you had MacFUSE 1.x installed via MacPorts, and some fuse filesystem ports that depended on 1.x, and MacFUSE 2.0 and some non-port filesystems that use it. Now that the port is up to date, this should be less of a problem.

I am rambling. I guess I'm really wondering if this is still a problem now that the port is updated to 2.0. If not, it may be best (certainly easiest!) to just leave things as is. Otherwise it may be worth making the macfuse port check for an existing installation.

[julien.cornebise@…]

Cc Me!

[julien.cornebise@…]

Hi Dan and all. I update this bugfix, as now MacPorts' MacFUSE again lags significantly behind recent MacPorts updates, especially regarding 64bits support, cf also bug #26115. So the problem is becoming pressing again. If at least MacPorts could incorportate some of the updates of MacFUSE, that'd be might nice =) (cf e.g. Tuxera's open-source build that has been circulated on MacFUSE's mailing list).

[drkp (Dan Ports)]

It's clear that there aren't going to be any future official releases of MacFUSE, and we've switched to Fuse4X as the default for new installations of fuse ports, so this seems moot now.

The fuse4x ports are better with respect to the issue described here. Unlike the macfuse port, it doesn't install files outside of $prefix, and won't install any files in the same place as the standalone installer, so they won't try to overwrite each other's files. It's still the case that only one kext version can be loaded, so there's a limit to how isolated the two versions are, but things should work if both installations are of the same version. It will also not conflict with a standalone installation of MacFUSE.