Not that this needs repeating in such esteemed company, but:
I do highly esteem those who post and read this list. And I don't mean to offend or be disagreeable, but I'm not sure it's repeated often enough.
"Do not assume that your package will be installed interactively via the GUI or on the currently booted volume." is the first of "The Commandments" for packaging on the above referenced page. It is important advice. And it is overlooked far too often. Except for exceptions in special edge cases, if your packages will only properly install on the booted drive, you are NOT doing a first rate job. I've spent lots of frustrating hours fixing packages that weren't well enough written to install on anything, but the boot volume. The only good news is that I got paid to do it.
(I'm not trying to offend anyone. But if any of this offends you, please get even by producing packages that are good enough that no one needs to pay me to fix them. And this applies primarily to apps that need to be installed by some kind of installer.)
Schools, businesses, enterprises, not-for-profits, and others (basically anyone with lots of Macs) are frequent are users of deployment solutions where the package needs to have a target (or be installed on) a volume other than what the Mac is currently booted from. If the original author doesn't plan for this, the results aren't always what you would want. (If the problem isn't obvious, consider Apple's NetInstall as an example. In this case the target Mac is booted from a server image while the software is being installed on the Target Macs hard drive. So the boot drive is a network drive, not the local drive where you want to install the software.)
Suppose you work hard, creating an app in a competitive niche? What if your competitor's app (or updates/upgrades) installs well in their environment, but yours doesn't? Haven't you just given your competitor an advantage? Is this something you (or your marketing department) really want to do?
Suppose your product is unique, or enough better that you win anyway. What happens then? Commonly, someone attempts to "repackage" your app so that it will work in their deployment environment. Is this person likely to know as much about your package as you? Are they likely to care as much that it works well, as you? Do you really want such people repackaging your app, that you've worked so hard on? Hopefully, the answers to these questions is "no".
In a more perfect world, Apple would care enough to develop a better Installer, that would take care of this for you, automatically. But it doesn't appear that we live in that world.
FREE BREIF ADVICE/THOUGHTS FROM AN AMATEUR REPACKAGER (thoughts from a newbee, humbly offered, worth every cent you paid for them, or maybe less. no warranty expressed or implied ;-)
From the very beginning, develop your installer package with the goal that it will install on any legitimate target. Don't fall into the trap of thinking you are going to add this later. Do it from the beginning.
For developing and testing your installer package, you want a test Mac that allows you to install on an OS that is other than the boot partition. And since things often don't work the very first time, it's nice to have more than one target partitions to test against. Consider setting up a Mac, with multiple OS partitions, for this specific function. When developing and testing your installer package, target one of other OS partitions other than the one you are booted from.
MacPro Towers are great, and if you can look your boss in the eye and convince her that you need one, great! But 750G, 7200 rpm laptop hard drives are now available for not that much $$$. You easily can put one of these in a Macbook, or a MacMini. Split the drive into a half-dozen or so partitions. Use one for a working partition, and put an OS on the others. Sometimes scripts get into trouble with paths that have spaces in them. So, I think it's a good idea to give your drives names that have a space in them. ( such as "Sand Box A" through "Sand Box E") That helps you catch these problems before you ship. You could manually install the OS on each partition. But if your smart & lazy, you might install it once, then clone it to the other partitions using SuperDuper, Carbon Copy Cloner, Disk Utility or some other solution. (I have a nice Deploy Studio workflow that will automatically partition the hard drive into 6 partitions, and installs 10.6.7 on 5 of them. I just start it, go to lunch and it's done when I get back. And I now have 5 clean partitions to do test installs on.) And if you've "dirtied" most of your partitions trying to get things to work and you want to try again, you can re-clone from a still clean partition. (or some of the other options supported by SuperDuper, Deploy Studio, etc.)
Scripts are probably the biggest problem. Develop, test and debug your scripts with the expectation that they will be installed on other than the boot volume. For most shell scripts, Apple's installer passes the target volume as the third parameter to your shell script. So, $3 will contain the path to the target drive. But since the path to the target volume may have spaces in it, don't forget to properly protect it. (i.e. use "$3" or "${3}", not just $3 I don't remember why, but someone recently said that "${3}" was better for some reason.) There may be exceptions, but in almost all cases, a "$3" or "${3}" should be part of most any target path reference. And if you do it right, the "$3" or "${3}" typically doesn't do anything that would keep it from installing on the boot volume. So you normally don't need to do two different scripts, or anything.
For development purposes, its nice to be able to debug scripts, without having to put them in a package and run the installer. One of the problems with using the $3 variable, is that it set by the installer during install. One quick and easy solution, is to use a different local variable, early in the script, which you assign $3 to. During development testing, you can make manual assignments, which you comment out later.
For example, during debugging, I might use something like:
Sample of script during debugging #!/bin/bash XYZ1= XYZ2=/Volumes/SL\ SandBox\ B/System/Library XYZ3=/Volumes/SL\ SandBox\ B XYZ4=
#XYZ4=
When you get ready to actually use it in an Installer Package, you might change what you comment out as shown:
Sample of script during debugging #!/bin/bash #XYZ1= #XYZ2=/Volumes/SL\ SandBox\ B/System/Library #XYZ3=/Volumes/SL\ SandBox\ B #XYZ4=
XYZ4=
**************************************** The above works well enough. But after a few times of forgetting to change my comments, I wanted a solution that would not require me to do so. The solution that I found to be helpful, was to make a separate calling script which would call the script that I was creating, and which would provide the test values for it. (I also wanted the ability to display some of the other environment variables. And I got tired of always looking up the Apple documentation and since I'm forgetful, I've put in lots of comment) I came up with the following to do the following.
To use it, put it in to a text (not rtf or office) file named something like "CallingScriptTest.command" and make it executable. Put it in the same folder with the script that you want to test. Set the A1, A2, A3, A4 variables to the values that you think the Installer will assign to $1, $2 and $3 in your test case. And replace "Name of Test Script" with the name of the script you are testing.
I'm not claiming its the only way to do anything. It is just something that worked for me, that I am freely sharing with the community.
**************************************** #!/bin/bash # # This script may be used to test other scripts intended for use in Apple Installer packages # before you are ready to actually include them in a package.
# To use, put this in a text file named something like"CallingScriptTest.command" and make it executable. # Place this text file in the same folder with the script that you want to # test. Then change the value of SCRIPT2Test to that scripts name # and change/add the parameters as appropriate
A1= A2=/Volumes/SL\ SandBox\ B/System/Library A3=/Volumes/SL\ SandBox\ B A4=
WORKING=`dirname "$BASH_SOURCE"` SCRIPT2TEST="Name of Test Script"
"$WORKING"/"$SCRIPT2TEST" "$A1" "$A2" "$A3" "$A4"
# # # The following is for debugging. To enable it, replace "1 -eq 1" with something that # evaluates to true, such as "1 -eq 1 ". If things are really confused, you may want to copy this # to the script you are developing, just to verify things really are, as you think they are. # ## if [ 1 -eq 0 ] then echo '$BASH_SOURCE =('$BASH_SOURCE')' echo '$WORKING =('$WORKING')' echo '$SCRIPT2TEST =('$SCRIPT2TEST')' echo '$A1 =('$A1')' echo '$A2 =('$A2')' echo '$A3 =('$A3')' echo '$A4 =('$A4')' echo '$@ =('$@')' echo '$# =('$#')' echo '$? =('$?')' echo '$0 =('$0')' echo '$1 =('$1')' echo '$2 =('$2')' echo '$3 =('$3')' echo '$4 =('$4')' echo '$5 =('$5')' echo '$6 =('$6')' echo '$7 =('$7')' echo '$8 =('$8')' fi
# # Notes: # Be careful about escaping spaces in file paths. #
# The following documentation is from Apple's Software Distribution Legacy # Guide. (2006-07-24) # ********************************* # Arguments # Provided by the Installer to script. # # When Installer runs an executable file, it provides the following # arguments: # * $1: the full path to the installation package; for example: # /Volumes/Projects/Testing/Simple_Carbon_App.pkg # * $2: the full path to the installation destination; for example: # /Applications # * $3: the mount point of the destination volume; for example: # / or /Volumes/External_Drive # * $4: the root directory for the current System folder: # / # Possible Environment Variables # These are the environment variables that a file may have access to # when executed: # * $INSTALLER_TEMP: # The scratch area used by Installer for its temporary work files. # This variable is always set. Executable files may use this area to # write data, but must not overwrite any Installer files. This # directory is erased at the end of installation. For example: # /tmp/.Simple_Carbon_App.pkg.897.install # * $PACKAGE_PATH: # The full path to the installation package. Same as the $1 argument. # For example: # /Volumes/Projects/Testing/Simple_Carbon_App.pkg # * $RECEIPT_PATH: # The full path to the directory containing the file # being executed. This is a location to which the package has been # copied. The location may vary from installation to installation. # # The executable can currently use this path to locate other files in # the package, but this may change in the future. For example: # /tmp/.Simple_Carbon_App.pkg.897.install/Receipts/Simple_Carbon_App.pkg/Contents/# # # Resources # * $SCRIPT_NAME:The name of the file being executed. Forexample: # preflight or postinstall # * $TMPDIR: # This variable is set when the user is doing a NetInstall or CD installation, # but is not set when the user is running on a local writable file # system. If set, it contains a path to a location on a writable # destination volume. # # Which Environment Variables a Script Can Access # The following list shows which scripts have access to which environment # variables: # * preflight: # No environment variables ar eavailable. # * preinstall,preupgrade: # $INSTALLER_TEMP,$PACKAGE_PATH,$TMPDIR # * postflight,postupgrade: # $INSTALLER_TEMP,$PACKAGE_PATH,$RECEIPT_PATH,$SCRIPT_NAME,$TMPDIR # * postinstall: # $INSTALLER_TEMP,$RECEIPT_PATH,$SCRIPT_NAME
#************************************************************************************ #************************************************************************************
On Mar 31, 2011, at 11:03 AM, Allister Banks wrote: Not that this needs repeating in such esteemed company, but:
Allister On Mar 31, 2011, at 11:06 AM, Karl Kuehn wrote: On Mar 31, 2011, at 1:03 AM, Stephane Sudre wrote: On Wed, Mar 30, 2011 at 9:11 PM, Karl Kuehn <email@hidden> wrote:
One thing that is missing in this conversation is that you could be running this installer targeted at a volume other than the boot volume. It is really simple to catch this case, so we should always be pushing people to do this when they write installer scripts. More inline:
Another solution is to only allow the package to be installed on the startup disk.
That restriction only takes effect for GUI installs. Command line installs blow right past it without even a warning in a log. So this would not help you on InstaDMG, System Image Utility, or weird cases with ARD. And given the number of installs out there done with InstaDMG or SIU, and the usually trivial nature of making installer scripts work in those environments, it is bad form to ignore them.
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
|