Repackaging iLife 11 for DeployStudio
iLife 11 can be difficult to repackage for use with DeployStudio. There is a great article available here on the OS X Deployment and Management Wiki for how to do this, but you can also use the methodology referenced in this post to repackage iLife 11 for installation by DeployStudio. See below the jump for the procedure.
Update – 3-24-2012: If you are reading this after Friday, March 23 2012, make sure to remove iLife 11’s package signing using Greg Neagle’s flatpkgfixer script prior to using the repackaging procedure below.
Prerequisites:
You’ll need to have the iLife 11 Install DVD or a disk image of that DVD.
Set up a new Iceberg project. Since we’ll need to run this installer with root privileges, I recommend setting the project type to Darwin: Package. That will open the project with the installation privileges automatically set to root. In this case, I’m naming the project iLife 11 Installer.
Open your iLife 11 install disk, then control-click on Install iLife and select Show Original.
A new Packages window will open.
Select all of the packages in the Packages window and drag them all into the Additional Resources section of your Iceberg project. (The order doesn’t matter.)
The last piece is telling the installers to run. For this, you’ll need a postflight script. Here’s the one I’m using:
—–
#!/bin/sh
sudo installer -dumplog -verbose -pkg "$1/Contents/Resources/iLife.pkg" -target /
—–
Once you’ve got the postflight script built, run the following command to make the script executable:
sudo chmod a+x /path/to/postflight
Last step, go ahead and build the package.
Once the package has been built, test it by taking it to a test machine that doesn’t have iLife 11 and install it. You’ll need to run Software Update a couple of times to get all of the iLife applications fully updated, but then it should be ready to go.
Note: When deploying an iLife installer package built using this method with DeployStudio, make sure to set it as a postponed install.
Leave a comment
Recent Comments
 | markandlucie on Migrating a Jamf Pro AWS-hoste… |
 | Dark on Creating root-level directorie… |
 | Ben LeRoy on Losing a giant |
 | Peter-Erik on Downloading installer packages… |
 | nathanhaggard on Losing a giant |
Der Flounder 
Are you sure that order does not matter? Future updates will run fine?
The order doesn’t matter because the postflight tells iLife.pkg to run. iLife.pkg handles the actual installation and installs the separate iLife packages in the order that they should be installed.
The $3 variable is the installer target passed to the script, so re-passing the target in the post flight script might be a cleaner way to go — it also works in DS as a non-postponed install.
#!/bin/sh
installer -dumplog -verbose -pkg “$1/Contents/Resources/iLife.pkg” -target “$3”
I just tried it using Rich’s script in DS 129 with a modular 10.6 image. I had a message that Lion DS does not support live installations, but far from that it worked OK.
I will the other script that Matt suggests.
Can I use the package produced to install it in modular systems using the installer command, in order to update these systems and use these OS+iLife images with DS?
Thank you all!
Kostas
that script does not work
Which script? The one in the post, or the one posted by Matt H?
How do i make that script run. This guide starts out good, but at the end its not so detailed. Or any screenshots that could help me understand. I am lost once i get to the post flight thing. then i have no clue of what to do next or even how to run the script.
Kim,
Please take a look at this earlier post that explains in detail the methodology used to build the iLife package:
I tried following every steps. But i Can’t make it through. The link you gave me does not explain how to make the preflight script? Do I Use text edit? Or what do I use?
Does anyone have this precompiled so i can just get it? 🙂 Pretty please.
Kim,
See here for an explanation of how you can create a script and make it executable:
http://www.askdavetaylor.com/how_do_i_create_a_shell_script_on_a_macintosh.html
As another option to running the flatpkgfixer you can just add the -allowUntrusted switch to your installer call before -target
I find it easier to add -allowUntrusted to your installer call before -target instead of running flatpkgfixer