site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com <installer-dev-bounces+xochitl_lunde=tripplite.com@lists.apple.com> wrote on 03/11/2010 10:23:51 AM:

I am trying to create a metapackage with PackageMaker 3.0.4/179. I have

dragged and dropped several packages into "Contents" area, and each one has

its own choice associated (so that I can set up Requirements). I need a

metapackage because it's the friendliest option for both end user (i.e.

personal computers) and managed computer (i.e. organizational computers)

installs.

The first sub-package imported is one I've built, and it works fine. It

shows an actual package icon in the Contents list, and PackageMaker

continuously prompts me to use its install resource for the installation.

The second and third sub-packages are individual packages provided by a

third party, so I have no real control over them. They are each for the same

non-Universal application -- so they are individual installers for Intel and

PowerPC editions of the same application version. (The packages are both

named the same.) When these are imported into PackageMaker, they show up as

folders and do not nag me about using the installer resources. No

information -- such as title, version, etc. -- is imported from the

packages.

When building, PackageMaker provides the same warning about the second and

third sub-packages:

"No payload could be found. The package will not be built."

Building the metapackage results in a bundle that contains a "Packages"

subdirectory with only the first package (the one I built).

The .pmdoc file is set up for a minimum target of Mac OS X 10.5 and the

metapackage is listed as a distribution. The second and third packages'

Requirements are set to try to enable their Choice only when the correct

architecture is encountered.

Without seeing or knowing more about the second and third package, can

anyone provide any guidance as to why they act so differently and don't

build into the metapackage?

Thanks!

--

Jeremy

Have you tried building your new package using Iceberg instead?  Maybe you will get some better error messages out of it, even if you discover you can't exactly do what you want. I really struggled with Package Maker in the last couple of months, and I spent a lot of time figuring out that it wasn't saving certain settings between runs. I have noticed that when I use package maker, it seems to make a binary file that I can't click "Show Contents" on like I can with most packages.  Finder seems to treat most of the third party packages that I have as directories, whereas the items made by packagemaker are being treated like single files.  I wonder if PackageMaker is then treating your other packages as folders and not as packages at all?  I am not very impressed with Package Maker, and I wouldn't be surprised if someone told me it doesn't work great with other packages that were not created using Package Maker. There are special rules about what kinds of packages can go in other packages also.  I'm not very familiar with them, but I remember seeing that somewhere.  It might be in the Mac OS X Software Delivery Guide.