[MacPorts] #29917: Fuse4X: add port

[MacPorts]

#29917: Fuse4X: add port
--------------------------------------+-------------------------------------
 Reporter:  anatol.pomozov@…          |       Owner:  dports@…                           
     Type:  submission                |      Status:  assigned                           
 Priority:  Normal                    |   Milestone:                                     
Component:  ports                     |     Version:                                     
 Keywords:                            |        Port:  fuse4x fuse4x-kext fuse4x-framework
--------------------------------------+-------------------------------------

Comment(by anatol.pomozov@…):

 >  * we are not going to replace macfuse with fuse4x, at least not right
 away. Both should be available as options; we might also have a port for
 OSXFUSE.
 Fuse4X conflicts with macfuse and OSXFUSE. How it should work? I would
 imagine something like a "virtual" package. i.e. there is will be a
 virtual package "fuse" and a few implementations (and only one of them can
 be installed).

 > At some later point, if it doesn't look like there are any problems, we
 can consider changing the default or marking macfuse as `replaced_by`.
 I though about replaced_by and it might work for macfuse. For that
 following changes have to be done:
  - kext - nothing as the only user of it is libfuse itself
  - libfuse - libfuse should use the same path and the same compiler flags
 as macfuse. Some changes to ./configure.am required. There is a question
 about changed macfuse-specific API. Any filesystem that uses only fuse
 specific API should be fine. Some other filesystems (e.g. SSHFS from
 macfuse) have to be patched to change it. After fuse4x is installed I can
 try to compile/check existing filesystems in the macports to see if it
 conforms fuse API. If it does not make sense to patch a filesystem - then
 those functions should be added back to fuse4x enabled with
 -DMACFUSE_COMPAT_MODE define.
  - MacFUSE.framework. It is installed outside of the macfuse tree.
 Symbolic link should be enough (??)

 >  * we do not need to support having more than one FUSE implementation
 installed, so it's OK if the ports conflict with each other on fuse.h. In
 fact, it may be better that way because there won't be any question about
 which one a given filesystem is using. Renaming the header files sounds
 like it could cause a significant compatibility issue for filesystems.
 >  * the fuse4x ports shouldn't conflict with an installation of MacFUSE
 installed outside of MacPorts. It doesn't look like they will, which is
 great since an improvement over the macfuse port. I don't think they will
 conflict with a standalone Fuse4X installation either although I imagine
 they won't actually be usable simultaneously unless they're the same
 version.

 Additional clarification:
 libfuse should not conflict as the library uses different path. In
 question are kext and framework.
  - kext. The same fuse4x cannot be loaded from several places and used at
 the same time. Following things will conflict between 2 instances of
 fuse4x kext: filesystem name, device file name, sysctl namespace.
  - framework, both macports and standalone installer uses the same path.

 Let me know if you want to make macports kext fully independent from
 standalone version. I'll give you more info about exact places need to be
 changed in kext.

 >  * existing filesystem ports should be able to build against either
 macfuse or fuse4x. This will take some changes but (I think) not major
 ones. I've already put together a patch for sshfs.
 >  * I'd wanted upgrading from macfuse to fuse4x to not require rebuilding
 filesystems, but I think that's unrealistic. There are substantive
 differences between the two, like the fact that MacFUSE has semaphore
 emulation and Fuse4X doesn't (FWIW, I agree with you that it shouldn't!).
 So it's OK if switching requires a rebuild.
 I think it would be possible - compiler flags and installation paths
 should be corrected in fuse4x. What about MacFUSE.framework?

 > All of this argues that we're basically in good shape with the portfiles
 as they are now. I need to test a couple more filesystems, and it would be
 good to have a release with the Leopard/Lion compatibility fixes I sent
 you. I also haven't tested anything that uses the Obj-C framework yet.
 Other than that, I should be able to commit it soon.

-- 
Ticket URL: <https://trac.macports.org/ticket/29917#comment:47>
MacPorts <http://www.macports.org/>
Ports system for Mac OS