site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com Mark Krenek Aspry Media On Oct 9, 2006, at 3:11 PM, Jim Dodd wrote: I know I could just try it but I did that back in OS X 10.2 and got so frustrated that I'd like to get a hint before I dive in again. Thank you, Jim Dodd Onset Computer Corp. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/mark%40aspyr.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.a... I've gone round and round on this same issue and there is no easy solution. Search installer-dev for my name and you'll see all my posts. I have not tried the newer "Distribution Packages" because they require 10.4 or later. But I doubt they solve this problem. Here are the main problems with using search methods (such as CommonAppSearch) in a package : - If the search does not find anything, then the install CONTINUES, installing everything in the default location that you have to specify in the package. Probably not what you want. - Even if the search method finds your existing software, it does not pass that info to scripts. Apple has confirmed this behavior. The installer does not provide the path of the found application to the script. After talking with Apple engineers, here is what we do. This is not pretty, but it gets the job done. - We wrote a wrapper app that goes around the package. The wrapper app locates the existing application, usually using LaunchServices. It writes the path of the found app out to a file in /tmp/ somehardcodedfoldername. This makes up for the fact that the Installer doesn't pass the found location to scripts. - If the wrapper app does not locate our app, it exits. If it finds our app, it launches the actual installer package which is bundled inside the wrapper app. This takes care of the case where the Installer insists on installing stuff even when your software was not located. - The installer package is designed to dump all it's files into /tmp/ somehardcodedfoldername. - We then have a postupgarde/postinstall script that reads the path of the found app from the file that the wrapper app left around in tmp. The script then moves/copies the stuff in /tmp/ somehardcodedfoldername to the proper location. Like I said, not pretty. And there's lots of gnarly details to tend to. You could possibly do all this in InstallationChecks or Preflights, but those have lots of gotchas. Hope this helps. I'm using PackageMaker. I haven't tried to use the Locator interface to find previously installed versions of our app since OS X 10.2 when it was very difficult to do. You had to enter detailed information in a TokenDefinitions.plist file. I could never get it to work and was never sure if I'd made a mistake in setting up the plist or just didn't understand how it was supposed to work. Now, with the newer, easier-to-use version of PackageMaker, I'd like to try again but one thing still eludes me. How does the Locater signal where the application was found? Specifically, I need to know the location in my preupgrade and postupgrade scripts. Is it simply that the location argument to the script (the $2 argument) is magically updated with the location? What is passed if the application cannot be found? This email sent to mark@aspyr.com This email sent to site_archiver@lists.apple.com