site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com John On 18-May-05, at 9:03, Joe Ridge wrote: On May 18, 2005, at 12:57 AM, Mark Douma wrote: /Applications/Utilities/foo/foo.app Thanks in advance, Mark Douma This email sent to ridge@umiacs.umd.edu _______________________________________________ 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... The key "IFPkgReceiptLocation" seems to be only on OS versions up to and including 10.3. On 10.4 it seems to have been replaced by "IFPkgRelocatedPath" which is likely a better name for it, though it does break backwards compatibility if you have scripts that rely on it. When you install a package in leaves a receipt package in /Library/Receipts. In this the receipt package the Info.plist has been modified to include the installation destination under the key IFPkgReceiptLocation. You should ba able to find a way to use this info for your update package. I'm having trouble with running a postflight shell script successfully after the installation of a package that uses a few search methods to locate the application bundle that's being updated. Here's an example situation that I'm dealing with: Let's say the application's name is "foo.app", and it's stored within a "foo" folder. The default location for the install is /Applications/, although it's relocatable and can be installed anywhere on the root volume. A person runs the installer and chooses to install the package into the /Applications/Utilities/ folder. The final path of the installed application then, is: During this install, a "postflight" script is run. This script needs to know the path to the "foo.app" application bundle where the user chose to install it. Using "$2/foo/foo.app" works great. $2 is resolved to wherever the user chose to install it. I now have a newer package version that needs to be installed. This package is meant for someone who already has a prior version of the application installed in the location of their choosing. What I would like to be able to do, if possible, is to have this package set up so that it's not relocatable, but so that it searches for and locates the existing installation wherever it might be. Since I need to choose a default location for the package, I choose the /Applications/ folder as in the original package. I choose the "foo.app" bundle and define 3 search rules for it: 1) CheckPath search method which looks at "/Applications/foo/foo.app" 2) CheckPath search method which looks at "/Applications/Utilities/foo/foo.app" 3) LaunchServicesLookup search method that should find the application if it's not found in either of the first two locations. As with the original package, I need to run a "postflight" script at the end of the installation. Again, the script needs to know the path to where the application bundle is that's been updated. As before, I'm attempting to use "$2/foo/foo.app" to refer to the application. This time, however, it's not working properly (or, at least it's not doing what I would like). I was assuming that, in this case, the $2 variable would be for the resolved installation path that was determined as a result of the search methods used above. Instead, it seems like only the default location for the install, the /Applications/ folder, is the path that's passed into the script as the value for $2. So, if the user had chosen to install the original package anywhere other than /Applications/, the "postflight" shell script will fail (which causes a problem and makes the overall installation a failure -- even if the install succeeds, if this script fails, the application won't be set up correctly). Is this the expected behavior, or any idea what I'm doing wrong? Is it possible to do what I'd like to do? I'm on OS X 10.4.1, using Iceberg 1.1.4 to create the package, and testing the package on 10.4.1. ---------------------------------------------------------------------- ----- Mark Douma Grand Rapids, MI, USA mdouma46@mac.com http://homepage.mac.com/mdouma46/ ---------------------------------------------------------------------- ----- _______________________________________________ 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/ ridge%40umiacs.umd.edu _______________________________________________ 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/ jkirkham%40alias.com This email sent to jkirkham@alias.com This email sent to site_archiver@lists.apple.com