Home > Mac administration, Mac OS X, Packaging, Scripting > Re-packaging metapackages with Iceberg

Re-packaging metapackages with Iceberg

One of the challenges that can crop up with deploying software packages can be repackaging metapackages, especially metapackages that don’t have the installers contained inside themselves. Good example of the latter is iLife ’11 and XCode 4.x, where the installer metapackage is small and instead acts as a master conductor to install other packages located in a separate directory.

To address this, you can use Iceberg‘s ability to add resources to a Iceberg-built package. Here’s an example, using an Office 2011 SP 1 installer metapackage and the Office 2011 14.1.2 Update.

Screen shot 2011-06-24 at 10.29.26 AM

To build, 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 Microsoft Office 2011 SP1 14.1.2

Screen shot 2011-06-24 at 10.35.04 AM

Once the Iceberg project opens, check the Settings section. You’ll want to make sure that the your information is filled in here (if you don’t know what to put in, check the Help menu for the Iceberg User Guide. The information you need is in Chapter 6 – Customizing component settings.)

Screen shot 2011-06-24 at 10.44.16 AM

You’ll also need to check the Options section, to make sure that Authorization: is set to Root Authorization.

Screen shot 2011-06-24 at 10.46.34 AM

Next, you’ll want to click on the Scripts section. In Scripts, scroll down as needed until you see the Additional Resources section. Now, go back to where you have your copies of the main Office 2011 installer and the 14.1.2 Update. Drag both installers into the Additional Resources section. (The order doesn’t matter.)

Screen shot 2011-06-24 at 10.32.03 AM

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/Office 2011 with Service Pack 1 Installer.mpkg" -target /
sudo installer -dumplog -verbose -pkg "$1/Contents/Resources/Office 2011 14.1.2 Update.mpkg" -target /

—–

Notice that the “$1/Contents/Resources” refers to the path to the package’s Resources folder. That’s where Iceberg will be storing these metapackage installers, in the installer’s embedded Contents/Resources directory. The script also governs what order the installers run in, so the main Office 2011 installer runs first and the update runs next after the first job finishes. The “-dumplog -verbose” flags are to help you track the progress of installation if you’re looking at the Installer log.

Once you’ve got the postflight script built, run the following command to make the script executable:


sudo chmod a+x /path/to/postflight


Once it’s been made executable, drag the script into the Installation Scripts section in the postflight line. Next, ensure the checkbox next to postflight is checked.

Screen shot 2011-06-24 at 10.33.33 AM

Last step, go ahead and build the package. (If you don’t know to build, check the Help menu for the Iceberg User Guide. The information you need is in Chapter 3 – Creating a package.)

Once the package has been built, test it by taking it to a test machine that doesn’t have the software on it and install. The end result should be that Office 2011 SP 1 installs and is fully up to date with the 14.1.2 update.

  1. Patrick Fergus
    June 24, 2011 at 7:38 pm

    Why Iceberg rather than Packages? Advantages or disadvantages?

    http://s.sudre.free.fr/Software/Packages/about.html

    • June 24, 2011 at 9:44 pm

      It’s mostly because I’m more familiar with Iceberg, having used it for a long time. I haven’t worked with Packages as of yet.

      • Gnarf
        June 28, 2011 at 6:06 am

        Iceberg builds “old-world” directory-type pkg/mpkg files.

        Packages builds only “new-world” flat file-type packages.
        Contents of flat packages cannot be “hacked” so easily.

  2. May 29, 2012 at 3:12 pm

    Brilliant, thanks for the ideas was able to get my stuff working after looking through this blog entry and another of yours. Thanks very much!

  3. Tim
    June 20, 2012 at 6:50 pm

    I want to use this technique to make a directory using mkdir in post flight script and copy a text file there into the USER area… which you cannot do inIceberg…. directory is created but is owned by root so after install application running under user account cannot write to that file in that folder because of root ownership…. any suggestions???

  4. June 20, 2012 at 6:55 pm

    Tim,

    You can set up a postlfight script to loop through the user directories and re-assign permissions based on the user name. Take a look at this script to get the general idea:

    https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/enable_java_web_plugins/enable_java_web_plugins.sh

  5. August 2, 2012 at 7:03 pm

    Thanks Rich for this article. Couldn’t really use your method in our environment for a variety of reasons, but it helped get the wheels spinning a bit, and I came up with a different method.

    In our case – we need the same package for manual install, base image install, and install via Self Service. And – where it really gets complicated – our users need some flexibility as to which components get installed (users can turn on French proofing tools, turn OFF PowerPoint, etc.), but there are a few components that we do NOT want installed under any circumstance. Therefore – we really need to run the installer as if we were running it from the ISO itself.

    My tool of choice – “Flat Package Editor” (/Developer/Applications/Utilities/PackageMaker.app/Contents/Resources/Flat Package Editor.app)

    We are assuming here that you have in hand the SP2 release of Office 2011 (which is delivered to you as a flat package). In our case – we wanted all proofing tools except English to be deselected by default, but to let users check on proofing tools for other languages if they desired. We also wanted Lync and Messenger to be deselected and disabled but not hidden. In other words, users could not install these apps, but it was not hidden from them. The steps below produced such a result.

    1. Copy “Office Installer.pkg” from the disk image to a writeable directory
    2. Open “Office Installer.pkg” in Flat Package Editor
    3. Select “Distribution” and then click “Info” icon, change “Basic Info” to “Preview” in drop down menu
    4. Select all the text of the xml file and copy
    5. Paste into your favorite text editor
    6. To deselect by default the additional language proofing tools, find lines that look like
    7. Add to the end of that line (before the “>” symbol) start_enabled=”true” start_selected=”false” start_visible=”true”
    8. New line should look like —

    9. What these mean:
    “start_enabled” – user can turn the item on or off if “true”
    “start_selected” – item is checked on by default if “true”
    “start_visible” – user can see the item in the list if “true”

    10. Find the other languages if desired, but be careful editing English if you want that one to stay selected.
    11. To disable Lync, find the line that looks like
    12. Add to the end of that line (before the “>” symbol) start_enabled=”false” start_selected=”false” start_visible=”true”
    13. New line should look like —

    14. Same thing for Messenger
    15. When done making your edits, save the file as “Distribution” — NO “.” suffix !
    15. Delete the “Distribution” file from the list inside the main window of Flat Package Editor
    16. Drag the edited file into the list.
    17. Optional – if you would like to make your package a bit smaller, you may also delete packages from the list that you have disabled in the Distribution file. Make sure not to delete any packages you want to let users install if they need them.
    18. From file menu – “Save”
    19. On an SSD drive – this goes really fast. On a HDD – can take a minute.
    20. Open the package in “Installer.app” – select “Customize” – and you should see the choices turned on and off as you specified.

  1. No trackbacks yet.

Leave a comment