Opened 9 years ago

Closed 9 years ago

Last modified 7 years ago

#32516 closed defect (invalid)

Remove macfuse port

Reported by: anatol (Anatol Pomozov) Owned by: drkp (Dan Ports)
Priority: Normal Milestone:
Component: ports Version: 2.0.3
Keywords: Cc: drkp (Dan Ports), cooljeanius (Eric Gallager)
Port: macfuse



I propose to remove macfuse port (or replace it with a dumb stub that installs fuse4x as a dependency). The reasons are following:

  • macfuse officially declared itself as a dead project. See its official page it recommends to use its forks instead.
  • fuse4x fork exists and actively used/developed for more that 6 months already. This is default fuse implementation both in macports and homebrew.
  • people still have problems on macports+macfuse. Here is a recent example of it some people complain that they cannot use CurlFtpFs+macports+macfuse and it was suggested to uninstall macports' version of macfuse and use macfusion application instead. The right answer here is to install fuse4x port instead of macfuse. fuse4x port fixes the issue described in the message. If that person had fuse4x then there should not be any issues.

Change History (7)

comment:1 Changed 9 years ago by pixilla (Bradley Giesbrecht)

Does fuse4x support the same older platforms and archs, ie. Tiger or PPC?

comment:2 Changed 9 years ago by anatol (Anatol Pomozov)

Fuse4X supports 10.5+ and very well tested on these platforms. At least on x86 arch.

As of PPC - I don't not have 10.5/PPC so I cannot carefully test everything on this platform. From other side I differs only in binary format and I do not expect much difference from 10.5/Intel. I know that Homebrew/PPC maintainer checked fuse4x on PPC and said that it works fine. Of course any feedback is welcome.

comment:3 Changed 9 years ago by anatol (Anatol Pomozov)

One more note to remember: macfuse library ABI differs from the Fuse4X one. If you are going to replace macfuse with fuse4x then anything who depends on fuse package should bump its revision number to force them to recompile.

comment:4 Changed 9 years ago by drkp (Dan Ports)

Owner: changed from macports-tickets@… to dports@…
Status: newassigned

I'm not sure we want to do this. As you point out, it would be an ABI compatibility-breaking change. That's hardly a showstopper, but I'd rather not do it in this case without a good reason. In particular, people may have filesystems built by hand (i.e. not with MacPorts) and linked against libfuse, and forcing them to needlessly recompile would be undesirable.

I don't see a very compelling reason to do this as we've already changed the default dependencies for fuse filesystems to fuse4x. So we're gradually migrating; new installations are almost certainly using fuse4x, especially on Lion. That means that anyone who has macfuse installed either explicitly requested it or has had it installed (and presumably working) for a while. In either case, it's not clear to me that they'd necessarily benefit from being migrated to fuse4x. (The obvious answer to this is 64-bit kernel support, but that's unlikely to be an issue for existing installations as the macfuse port refuses to build on a 64-bit kernel system.)

comment:5 Changed 9 years ago by anatol (Anatol Pomozov)

This question is discussed in the maillist

The maillist list is better place for discussing this type of questions so feel free to close this ticket.

comment:6 Changed 9 years ago by drkp (Dan Ports)

Resolution: invalid
Status: assignedclosed

comment:7 Changed 7 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

Note: See TracTickets for help on using tickets.