Today I needed to view the contents of OS X's SDKs, which are published as .dmg's.

To my surprise, I discovered that the structure is as follows :

  • The .dmg contains a hidden .pkg files
  • The .pkg files contain a Payload file, which is a .gz or a .bz2, depends
  • The .gz contains a single cpio-compressed file
  • This cpio archive contains all the files.

Can anybody provide technical and/or historical reasons why this is done this way ?

Just to be clear : I don't have any technical problem, I'm just curious.

  • How would you have done it? What exactly is your surprise? – nohillside Apr 27 '13 at 16:47
  • Well for instance, Android packages are just a .zip file with the right structure (just like a compressed .app). I understand that the above structure probably appeared progressively, but 4 levels of imbrication seem a bit much to me. Which is why I asked for any historical hint. – Calvin1602 Apr 28 '13 at 12:03
  • zip is the same as gz and cpio (or gz and tar) combined actually – nohillside Apr 28 '13 at 14:12
  • The .dmg is the disk image which is mountable like an external file. The value it provides here is that .dmgs are checked for consistency/correctness upon mount, so if the download went wrong you will get notified
  • The .pkg is the standard format for installable software and usually contains not only the application itself but all the other stuff displayed during installation: ReadMe, legal/license information, optional packages etc.
  • The .gz is to compress the data and keep the packages smaller on disk (and for download)
  • .cpio is an archive format similar to tar etc.
  • But .pkg is already a compressed XAR archive... Why a .cpio in a .gz in a .xar ? – Calvin1602 Apr 28 '13 at 12:00

Historically speaking, pkg format comes from Unix packages (more directly the BSD ones), which are essentially the compressed payload (files in a folder structure equivalent to one they'd end up on disk), and some additional metadata and instructions to drive the installer wizard, and write information in various system databases.

A dmg file is just a disk image similar to what you would get with a dd-type utility. In Mac application distribution it is in a HFS format similar to the one HFS formated partitions on optical media contain.

Now, not all DMGs contain .pkg files. Some DMG images contain just .app bundles (which, again, is nothing more than a folder with all resources an application contains, but as the folder has extension .app Quartz/Finder treat it as one file, much like they do with folders ending in .kext or .component etc.)

Hidden files are there to hide complexity, and for other "user experience" type reasons.


Well, the structure of a .pkg isn't that more complex or obscure than that of a Debian .deb — both are archives containing another compressed archive for the actual contents plus metadata along it (which in a .deb is inside another layer of compression just like the payload!)

About the hidden files in the DMG, there's no scientifically proven answer: one could just speculate about copy protection (an arguent which obviously doesn't stand) or an overzealous attempt to hide the "technical background" from the user (as supported by the contents of a [Mountain] Lion InstallESD.dmg which, not having being intended to be accessed by a human user, has some visible folders with functionality that was fulfilled by invisible ones in CD and DVD releases of Mac OS X)…

Add to this that since 10.5 there can be a further layer due to the existance of packages and distributions/metapackages (used to group together packages with a components-to-be-installed selector and apparently required, at least with Apple's dated and limiting PackageMaker, to use various advanced features such as digital signatures or some system requirement checks).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .