On Thu, Jun 12, 2008 at 8:33 AM, Dave Koziol <[EMAIL PROTECTED]> 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.
Thanks for adding another data point to this discussion. Offtopic: I'm curious what Missing Sync for Windows Mobile is using MacFUSE for. I've seen the PackageMaker issue with at least one other product aside from ExpanDrive. It seems that PackageMaker will re-write the bundle identifier and version string as well as remove whatever was in the Resources directory when you drag a .pkg into the interface. Please double-check the MacFUSE Core.pkg in your created .mpkg to make sure that this isn't happening to you as well. I've been told that this problem does not seem to occur if you use Iceberg to create .mpkgs. > > 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. Can you describe what the less than ideal experience is? Is it simply that it doesn't tell you in advance the estimate of how much disk space it'll take up or is there something else that I'm missing? It looks like if I remove the key from the Info.plist.in that is used to generate the "MacFUSE Core.pkg" then it will be created and filled in properly by packagemaker. I'm happy to get that change in for the next release if it solves your issue. In the future, please don't hesitate to let us know about such issues. I won't guarantee that we'll fix things, and we might disagree about what needs fixing or how things should be changed, but if we don't even *know* that you are having a problem then it doesn't help anything. > > 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? Our current practice is to tag the tree when we do an official release and then increment the version number in svn. I'm not too worried about people who build and install from the head of the tree on their own. If they can manage that then I expect them to be savvy enough to realize why MacFUSE-based file systems they are using might have problems. Really only developers should be doing this. I also think this case is extremely rare. What I do worry about is people distributing builds from the head of the tree. I think we can all agree that this is a bad idea. ted > > 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 -~----------~----~----~----~------~----~------~--~---
