These last two posts are very good at stating the problem at hand. We also have a product which will depend on MacFUSE and knew this was going to be an issue and had decided to proceed as follows.
The MacFUSE package is a system resource which we would carry as an other package in our installer, if not installed we would install a released version of MacFUSE. If a version were already installed we would check the installed version for compatibility. Ninety plus percent of the time the user will probably have a compatible version. If the incompatibility is due to an unknown version e.g. trunk, we would throw up a dialog and ask the user to let us install a known version and bail if not permitted. This implies, that after a release is placed in the tags the version number changes in the trunk. Our software update would install a newer version of MacFUSE if we needed to upgrade the MacFUSE for some reason, as long as we are compatible with the installed we would not need to upgrade MacFUSE. If the user happens to upgrade MacFUSE from another app or any other method, again our compatibility check would determine the course of action. I note that Parallels also is using a fusefs, I glanced at their installer package but could no evidence of how they are installing or using the file system. On Jun 12, 2008, at 8:33 AM, Dave Koziol wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
