Archive for the 'PackageMaker' Category

System vs. Target in PackageMaker

Saturday, July 25th, 2009

The PackageMaker user guide doesn’t explain the difference between “system” and “target” in PackageMaker’s pop-up of Requirement criteria:

For example, “System OS Version” versus “Target OS Version”.

So now that I’ve figured it out, I’ll fill in the gap for you.

  • System is the volume that the installing user is booted from.
  • Target is the volume that the Requirement is testing. (Your Requirements are applied for each volume.)

So if you want to make your Installer package installable to any bootable volume, make it installable to any volume and add a Requirement for Target OS Version. (Another method you may try is “File Exists on Target: /Library”.)

If, on the other hand, you want to make your Installer package installable to the Home folder, make it installable only to the Home folder and add a Requirement for System OS version.

How you can get this wrong

If you make your package installable to the Home folder but test the Target OS Version, your package is broken: It does not work for those of us who have our Home folder on a non-bootable volume (in my case, separate from two other, bootable volumes). You must use the System OS Version, and hope for the best.

If you make your package installable to any volume but test the System OS Version, your package is broken: The user will be able to install your software to a volume whose version of the OS cannot run it. You must use the Target OS Version.

As far as I know, there’s no way to make a package that does both properly, since the choice of any volume, booted volume only, or Home only is per-package, not per-choice or per-contents.

Dramatic twist ending

The above is good if you’re targeting Leopard. If you still support Tiger, there’s a twist. (Obligatory video link.)

GrowlMail is a good example. As a Mail bundle, it requires a couple of user-default settings to work. That makes installing to /Library pointless, because the settings will only be set for the user who installed it, so it won’t work for any other users on the system.

Leopard allows installing to ~, so that’s easy: I use System OS Version, as I suggested above.

But Tiger’s Installer can’t install to ~. The same Installer package that works on Leopard does not work on Tiger (I even tested with earlier betas—it has never worked in any 1.1.6 beta). I don’t know how nobody noticed this, not even our Tiger testers.

The Installer package for Tiger must target /Library, since I can’t do the proper thing on that OS version, so I must make separate GrowlMail packages for Tiger and Leopard.

  • The Leopard package installs to ~/Library and uses System OS version, as I suggested above.
  • The Tiger package installs to /Library and uses both Target OS Version and System OS Version:
    • If the user is running on 10.5 or later (System OS Version ≥ 10.5.0), the package tells them to use the other package. (The other package has a similar check.)
    • If a destination volume does not have 10.4 or later installed on it (Target OS Version < 10.4.0), the package tells them they can’t install there.

This is what you’ll find in Growl 1.1.6b4 and 1.1.6 final. It’ll go away in 1.2, since we’re dropping Tiger then.

WWDC 2007 session videos are out

Monday, July 30th, 2007

If you attended WWDC, you can head over to ADC on iTunes and see what you missed.

Apple bug Friday! 45

Friday, July 14th, 2006

This bug is Can’t drag-and-drop to “Title” field on PackageMaker’s Interface tab. It was filed on 2006-05-19 at 02:38 PDT.


Summary:

The “Title” field on the “Installer Interface” tab is not a drop target.

Steps to Reproduce:

  1. Drag text from the “Title” or “Description” field to the “Title” field.

Expected Results:

The cursor changes to the Copy cursor, and when the mouse button is released, the text is inserted at the drag destination insertion point.

Actual Results:

The cursor does not change, and when the mouse button is released, the drag snaps back.

Regression:

None known.

Notes:

None.


Technorati tags: ,

Apple bug Friday! 44

Friday, June 30th, 2006

This bug is PackageMaker’s keyboard shortcuts are not consistent with Xcode’s. It was filed on 2006-05-19 at 02:28 PDT.

The list in the Notes section is adapted from another blog post of mine, Know your Xcode.


Summary:

PackageMaker’s keyboard shortcuts for Build, Build Log, Run, and Run Log do not match up with Xcode’s shortcuts for the same commands.

Steps to Reproduce:

  1. Press ⇧⌘B.

Expected Results:

The Build Log appears.

Actual Results:

*Beep*

Regression:

None known.

Notes:

Xcode has a simple and elegant system for its keyboard shortcuts:

  • ⌘_ builds, then performs the action.
  • ⌘⌥_ performs the action without building. (Exception: Build’s keyboard shortcut is ⌘B, presumably because it is impossible to build without building.)
  • ⇧⌘_ shows the log for the action.

PackageMaker should adopt the same schema, both for its elegance and for uniformity with Xcode.


Technorati tags: ,

Report-an-Apple-bug Friday! 42

Friday, May 19th, 2006

This bug is PackageMaker (and Installer?) does not support EPS, PDF, or SVG in packages. It was filed on 2006-05-19 at 02:20 PDT.


Summary:

PackageMaker/Installer should support the use of EPS, PDF, or SVG image files in Installer packages.

Steps to Reproduce:

  1. Create a package in PackageMaker.
  2. On the first step of the Interface Editor, drag a EPS, PDF, or SVG file onto the window, or click Custom Background Picture and choose a EPS, PDF, or SVG file.

Expected Results:

The EPS, PDF, or SVG file is accepted as the background of the package.

Actual Results:

The EPS, PDF, or SVG file snaps back (drag), or is disabled in the list (choose file).

Regression:

As far as I know, Installer has never supported EPS, PDF, or SVG files.

Notes:

Vector graphics would scale cleanly to any resolution, which is good for the coming resolution-independent UI. Currently, it is necessary to use a large and/or multi-image TIFF file, and hope that it’s enough.


Technorati tags: ,

Report-an-Apple-bug Friday! 41

Friday, May 19th, 2006

This bug is PackageMaker (and Installer?) does not support PNGs in packages. It was filed on 2006-05-19 at 02:00 PDT.


Summary:

PackageMaker/Installer should support the use of PNG image files in Installer packages.

Steps to Reproduce:

  1. Create a package in PackageMaker.
  2. On the first step of the Interface Editor, drag a PNG file onto the window, or click Custom Background Picture and choose a PNG file.

Expected Results:

The PNG file is accepted as the background of the package.

Actual Results:

The PNG file snaps back (drag), or is disabled in the list (choose file).

Regression:

As far as I know, Installer has never supported PNG files.

Notes:

PNG supports compression, for smaller Installer packages. True, Installer packages are often distributed on compressed disk images or in compressed zip archives, but PNG can “filter” the image bytes to be more compressable, resulting in greater savings.


Technorati tags: ,