Flat Package Editor For Mac 2008
Andrew Henson
Now, for 10.3 and earlier, right-click OSInstall.mpkg and choose Show Package Contents. Open Info.plist with TextEdit or a .plist editor. Near the bottom, there will be something like OSModelCheck that will have a model underneath it (in TextEdit) or beside it (in most other .plist tools), such as PowerMac3,1. Delete the whole thing (the key and the model), save the .plist file, and you're good to go. You may, though, want to check the Info.plist files of some bundled software such as AppleWorks to make sure that others don't have the model check, as some packages on my 10.3 disc did.
For 10.5 and 10.6, the editing process is the same as for Tiger, but with a twist: you need to open OSInstall.mpkg with PackageMaker, which is why you need the Developer Tools. When you open it, hit the tab called Requirements and double-click the top Javascript. Edit it the same way as described with Tiger and hit OK (or Save or whatever). If you are concerned about cosmetics, change the name from MacOSX_Title to Mac OS X; otherwise it will say "Select which disk to install MacOSX_Title on". Build the package (don't worry about all the other packages) and rename it to OSInstall.mpkg. Drag it to the Packages folder on the image, choose Replace, and you're done.
I just happened to have Gray install CD's for 10.5.3, and 10.6.4 (didn't realize I had 10.6 until I had already bought 10.7). Downloaded Tinker Tool from the internet. I used Pacifist to retrieve the flat package editor from the 2nd 10.5.3 installation CD (flat package editor from 10.6 wouldn't work since I was running 10.5. ) Edited the Distribution file in 10.6.4 and voila, after a couple of Software updates I'm running 10.6.8 with App Store. Downloading 10.7 now...Jury is still out on whether it will run on my machine. In any event I only need 10.6 to run the robotics software, so its been a success! Thanks fusion71au for the help!
Edit: I have also tried to use pkgutil to expand, edit Distribution, and reflatten a flat package. This gets the icons and readme in the installer, but the installer is then unable to unpack the payload. Same if I reflatten with Flat Package Editor. I have also tried to create an expanded package without PackageMaker (which works, except on 10.8), but when I try to flatten that with pkgutil the result is a corrupted package again.
Check out the Luggage - it's a Makefile helper file that lets you create OS X packages with sane Makefiles. Disclaimer: I am the original author for it, though there are a lot of other people's contributions in it now.
I am new to macs, but when I try to look for something similar for OS X, all I find is software to make packages from scratch (PackageMaker, Iceberg, etc.), but nothing for editing already created .pkg files.
So here is the question: is there a way to easily edit the content of .pkg file (replace some files, add a script, etc.), without having to install/unpackage it and then package the configured stuff back?
I am not aware of any Apple recommended tools to edit existing package, pkg or mpkg, files. Most packages are signed and thus any changes will invalidate their signature; although resigning is simple enough using pkgbuild and an appropriate installer certificate.
Consider creating a wrapper multi-package that adjusts any required files after installation. With this approach you can bundle up existing packages and then run post-install/update scripts as required.
There is little documentation about crafting packages as Apple traditionally relied on the graphical tool PackageMaker. Since Mac OS X 10.8, the PackageMaker tool has been replaced by the command line tools productbuild and pkgbuild.
The tool you will want to investigate is pkgbuild. This tool eases the creation of packages containing multiple packages and scripts. About Distribution Definition Files talks about the internal file format.
In today's article, we will look at the new flat package format. First, we learn how this format compares with earlier bundle-style formats. Then we examine the structure of a typical flat package. Finally, we look at three useful tools with which to manage the package.
When PackageMaker starts a new project, it displays its sheet dialog Install Project (Figure 1). Use this dialog to supply some basic information about your project. For instance, in the Organization field, enter a unique ID for the package. Convention dictates that you use your product or company's URL as the ID string. Make sure to enter the string using reverse-domain syntax. If your product URL is www.foobar.com/foo, then type the string as com.foobar.foo.
Next, from the pop-up menu Minimum Target, choose which OS target you plan to support at least. This menu provides three choices: Panther (10.3), Tiger (10.4), and Leopard (10.5). By choosing an OS target, you set the format of your final installer package.
Assume you have chosen 10.3 as the minimum OS target. Also, assume your installer project has only one payload. If you choose Build from the Project menu, PackageMaker stores your payload inside a payload package, also known as a component package. This package is the simplest of four possible packages.
Figure 2 shows the structure of a typical payload package. As you can see from the diagram, the package is, in essence, a bundle. Its root directory, Contents, contains four items, which are listed as follows.
- An XML file containing the default settings for the entire package. To view its contents, use the Property List Editor tool. You can also view the file with a text editor, if you are familiar with XML.
Assume again that your minimum OS target is 10.3. But this time, you have more than one payload in your installer project. Or you have customized the install panels using PackageMaker's Interface Editor. Or you used external scripts to customize the install session. When you choose Build from the Project menu, PackageMaker builds the installer package as a meta-package (Figure 3).
In a meta-package, each payload is stored as a payload package in Contents/Packages/. Any files used to localize the install panel go into the correct lproj bundle in Contents/Resoures/. External scripts that customize the install session also go into Contents/Resources/.
But the meta-package does not let you customize the Conclusion panel nor the payload choices. It does not support scripts written in Installer JavaScript. And it cannot display just the Easy Install or Custom Install panels -- it has to display both panels.
Now assume you have 10.4 as your minimum target. In this case, when you choose Build from the Project menu, PackageMaker builds your installer package as a distribution package (Figure 4). At first, its structure appears similar to that of the meta-package. A distribution package, however, has several advantages over a meta-package.
Finally, assume you selected 10.5 as your minimum OS target. (In Snow Leopard's PackageMaker v3.04, "10.5" remains the highest target OS). Now, when you choose Build from the Project menu, PackageMaker builds the package as a flat file, not as a bundle. As a result, you can no longer view the package's contents from the Finder using the Show Package Contents menu.
The flat package uses a structure different from the previous three formats (Figure 5). First, it does away with the Contents directory, and certain files like Info.plist and PkgInfo. Second, it keeps its main items like payloads and resources at the root level. Third, it renames the distribution.dist file as simply Distribution. It still, however, uses lproj bundles to store any localized files.
The flat package also uses a more compact format for its payloads. Each payload package now has three files, instead of the bevy of items from older formats (see Figure 4). The Bom file takes the place of Archive.bom. The Payload file replaces Archive.pax.gz, using gzipped cpio as an archive format. The PackageInfo file, on the other hand, is an XML rendition of PkgInfo.
Finally, the flat package stores its install scripts differently. A pre- or post-install action, for instance, becomes an action payload (Figure 6). Its payload name consists of the main package name and the action type.
On the other hand, pre- and post-install scripts for each payload combine into a single Scripts file, which is then stored in each payload package (Figure 7). This Scripts file uses specialized tags to identify and separate each script. I have, of course, covered pre- and post-install actions and scripts in a previous MacTech article.
Since the flat package is a single file, it is much easier to distribute over the network. Bundle packages, on the other hand, needs to be "repackaged" in another form like a disk image or a zip archive. But the flat package is supported only on OS X 10.5 or newer. It harder to customize after being built, and it does not support installer plug-ins.
PackageMaker 3.0 comes with three tools that you can use to work with flat packages. One tool, the Flat Package Editor, lets you view the package's contents, as well as make some simple changes. Obviously, you cannot use this tool to open one of the three bundle packages. Doing so will only result in an error.
There are two ways to start the editor. The first way is to choose Launch Flat Package Editor... from the Edit menu of PackageMaker. After the editor launches, choose Open from its File menu, and use the Open File dialog to select the flat package. Click the Open button to open the selected package.
The second way is to select the flat package with a Control-click. Then choose Flat Package Editor from the Open With contextual sub-menu. Both approaches will display the package contents as a hierarchical list (Figure 8). Bundles and directories inside the package appear with a triangle widget next to their icons. Clicking the triangle displays the contents of that bundle or directory.
Assume you want to add a new item to the flat package. To add a file, drag the file from the Finder to the editor window. Once the editor highlights the desired position in the package, drop the file at that position (Figure 9). The editor then copies the file into the package. If the position happens to be in a bundle or directory, the editor reveals its contents prior to the drop.
dd2b598166