macfuse

[Jordan K. Hubbard]

On Dec 23, 2011, at 1:17 PM, Dan Ports wrote:

> One argument against removing the port is that fuse4x isn't ABI
> compatible with MacFUSE. That's hardly an issue for dependent ports, of
> course, but would break compatibility with non-MacPorts binaries that
> link against the framework. I'm told that's an issue for some MacFUSE
> users, although it's not clear how many of them are getting it from
> MacPorts (or if it's really something we want to support anyway.)

I can understand the argument, but again, given that MacFuse has been abandoned for almost 5 years now, that seems more like an argument for it to leave macports since it doesn't even compile on anything of recent vintage, and for the folks who are still stuck on PPC (which is also completely deprecated, even as an emulation target), they're likely living off the old precompiled packages from other sources in any case.

This does, however, open a larger can of worms concerning what the default support footprint of macports should be, and not so much from the perspective of "how many releases back" to go but what the default/supported compilation targets should be.  If it were up to me, and of course it's not, I would declare that all executables should be x86_64 and all libraries/frameworks be i386/x86_64.  Anyone wishing to create binaries for older architectures could simply grab an older release of macports and stick it on an older machine, since any desire to go retro like that is almost certainly driven by the need to create software which is equally retro.  If macports had binary packages (Internet: "Oh god no not that subject again!"), it would be even easier to just snapshot the binary package archives and point the retro folks in that direction. ;-)

- Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20111225/ee0a3cc6/attachment.html>