Re: "postflight" shell script and $2 variable + Search methods
Re: "postflight" shell script and $2 variable + Search methods
- Subject: Re: "postflight" shell script and $2 variable + Search methods
- From: John Kirkham <email@hidden>
- Date: Wed, 18 May 2005 09:34:37 -0400
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.
John
On 18-May-05, at 9:03, Joe Ridge wrote:
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.
On May 18, 2005, at 12:57 AM, Mark Douma wrote:
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:
/Applications/Utilities/foo/foo.app
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.
Thanks in advance,
Mark Douma
----------------------------------------------------------------------
-----
Mark Douma
Grand Rapids, MI, USA
email@hidden
http://homepage.mac.com/mdouma46/
----------------------------------------------------------------------
-----
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden