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: Joe Ridge <email@hidden>
- Date: Wed, 18 May 2005 09:03:05 -0400
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:
40umiacs.umd.edu
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