For Missing Sync for WIndows Mobile, we us a Meta Package for our installer, and we just have MacFUSE as one of the various packages we install. This allows us to ship the MacFUSE package as delivered. In the event someone turns off MacFUSE in our installer, and tries to use our functionality which requires MacFUSE we just tell the user to go reinstall. While it is possible for the users to customize the installer, the reality is that most users don't do this, and if they do they just need to run the installer again.
Our only "issue" with the Package as currently distributed is that the info.plist file contains a IFPkgFlagInstalledSize with a size of 0. This results in a less than ideal experience and we currently work around this by removing that key from the Info.plist file. But we'd like to see the next release of MacFUSE built in such a way that this is no longer required by us. I would agree with the others, we would really prefer to see everyone distributing the standard MacFUSE and working to resolve any problems in that distribution rather than customizing the installation. Is the version number in svn kept in such a way that we at least have a hope of detecting someone who has a version of MacFUSE built from the trunk as opposed to an official release? On Jun 12, 2008, at 11:01 AM, Jon Shea wrote: > Hi Amit, Dave, and Ted, > > I work with Jeff at Magnetk. I'm concerned about our MacFUSE > distribution problem as well. We need to distribute MacFUSE with > ExpanDrive; we'd consider it an unacceptable user experience if our > users had to install MacFUSE themselves. But we can do a better job of > it. > > In the future we will have ExpanDrive check the installed version of > MacFUSE, and offer to upgrade if necessary. If the user declines to > upgrade, then we will refuse to run. We will also fix the issue with > our MacFUSE installer, including existing installations. As long as > we're installing MacFUSE as a shared resource it's important that our > installation be exactly the same as yours, and it's embarrassing that > our mistake makes the uninstaller fail. I apologize. > > I think that a lot of libraries present present a dilemma as to > whether they should be installed as a shared resource, or if they > should be installed separately by each vendor (Gems in Ruby on Rails > applications, or the Sparkle framework, for example). If each vendor > installs their own copy, then system resources are wasted on > redundancy. > > But if every vendor shares the same installation, then they have to > trust every other vendor to be a good citizen when it comes to > managing that library. Even if every version of MacFUSE is perfectly > backwards compatible, it's possible that a filesystem will "depend" on > a bug in MacFUSE, and that the filesystem will break if MacFUSE is > upgraded by a different vendor. > > There's no perfect solution to this dilemma. As the number of MacFUSE > filesystems in use increases, we're likely to run into it again. With > that in mind, we want to do everything we can to be a good citizen. > Thank you for your help. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "macfuse-devel" group. To post to this group, send email to macfuse-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/macfuse-devel?hl=en -~----------~----~----~----~------~----~------~--~---
