Reorganize 'fuse' ports

[anatol (Anatol Pomozov)]

Macfuse project is dead, fuse4x its successor is more and more widely used. Macfuse in macports has issues with Lion (Finder, deadlock, ...) as well as improper locking in 64bits kernel.

My suggestion is to dump macfuse and make fuse4x as a default fuse api implementation.

Dan mentioned that he wants several fuse api implementations in macports. In this case we need to handle this situation correctly. The plan is following:

• Add a virtual package "fuse". The only purpose of it is to have a dependency to default fuse implementation ("lib:libfuse.dylib:fuse4x").
• All fuse filesystems should depends on this virtual fuse package.
• All fuse api implementations should be ABI compatible (the same library name, the same compile flags, ...)
• Remove macfuse.

[ryandesign (Ryan Carsten Schmidt)]

Replying to anatol.pomozov@…:

• Add a virtual package "fuse". The only purpose of it is to have a dependency to default fuse implementation ("lib:libfuse.dylib:fuse4x").

Do not use "lib:" (or "bin:") -style dependencies unless you want a library (or binary) outside of MacPorts to be able to satisfy the dependency -- which you almost never want.

[anatol (Anatol Pomozov)]

Do not use "lib:"

Or path (e.g. "path:lib/pkgconfig/fuse.pc:fuse4x") or some other mechanism that you think the best of all here.

My idea was that "fuse" port should be a virtual package that does not contain any source, just dependencies.

[mf2k (Frank Schima)]

Cc Me!

[bgrupe27]

Cc Me!

[drkp (Dan Ports)]

I'm not sure I see any particular benefit to having the virtual package over declaring path: dependencies as we're currently doing.

I am giving some thought to replacing macfuse with fuse4x as the default fuse dependency for new installations, or removing macfuse entirely and making it replaced_by fuse4x. Normally, I would be inclined to wait for a while because fuse4x hasn't been available very long and it isn't clear how the situation with the various MacFUSE forks is going to shake out. But given that macfuse is unusable on most Lion systems, and fuse4x looks to be strictly an improvement (haven't heard any major complaints) we may want to do it now.

[anatol (Anatol Pomozov)]

I'm not sure I see any particular benefit to having the virtual package over declaring path: dependencies as we're currently doing.

Currently we explicitly use macfuse dependency in every filesystem port. If we would have a virtual package then the macfuse/fuse4x dependency will be only in one place (as default implementation of the fuse interface). And it would be easier to change it. At least it is how it is done in APT or some other linux package managers.

But if you think that it is ok to have macfuse/fuse4x dependency in every filesystem port then I am ok as well.

[drkp (Dan Ports)]

I don't think there's any benefit to having a metaport for the dependency.

But I've changed the default dependency for fuse ports to fuse4x in r83483. If macfuse is already installed (or explicitly installed), it can still be used.