• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Requirement Check For Initial State
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Requirement Check For Initial State


  • Subject: Re: Requirement Check For Initial State
  • From: Stéphane Sudre <email@hidden>
  • Date: Sun, 16 Mar 2008 02:10:58 +0100


On Mar 15, 2008, at 12:23 AM, Adam Halls wrote:

Hi,

I'm using PackageMaker 3.0.1. I've created a new package that will only run on Mac OS X 10.5+. I've read the PackageMaker documentation several times and have scoured the internet to find answers to the following questions, but I've had no luck.

1. I have two components that I need to install:

Database Engine
My Application

For the Database Engine I have the Initial State set as "Selected" and "Hidden" are disabled and "Enabled" is enabled. However, I would like to add a requirement that would set "Selected" to Yes and "Enabled" to No if the Database Engine needs to be installed. I have written a shell script that checks to see if the Database Engine needs to be installed:

----------------------------
#!/bin/sh

if [ database_needs_to_be_installed ]
then
	exit 1
else
	exit 0
fi
----------------------------

So I select the Database Engine component and click the "Requirements" tab and add a new requirement:

if: Result of Script
file path: path_to_script

Selected Yes
Enabled No

But no matter what I set the exit values to in the shell script the package always thinks the script is failing. This means that Selected is always set to Yes and Enabled is always set to No.

What is the proper way to have a script exit with either true or false depending on the if statement?
Should I be using a shell script or another script technology such as Perl?

As far as I can tell, you won't be able to do what you want with this release of PackageMaker.


When you select a "Result of Script" requirement, this will use a system.run call in the distribution script.

  Issue #1:

According to the Installer Javascript Reference documentation: "The alllow-external-scripts attribute of the options element in the distribution definition must be 'yes' for the program to be launched.".

I'm sorry to report that the package built by PackageMaker 3.0.1 does not set this attribute to yes, it's still set to no.

Bug ID# 5801794


  Issue #2:

You will notice that the documentation even has a typo on this attribute: 3 l's for allow are not going to make it work better.

	Bug ID# 5801793

  Issue #3:

When you define the script to be executed, the script is not integrated into your package.

	Bug ID# 5801796

  Issue #4:

When you define the script to be executed, the path used for system.run is the one of the script on your hard drive (absolute path).

	Bug ID# 5801798

  Issue #5:

The documentation for system.run is quite incomplete and does not provide any information regarding what "true" or "false" could mean for a shell script.

When a shell scripts works, it usually returns 0. The issue is that 0 means FALSE in most coding languages.

	Bug ID# 5801800

  Issue #6:

I'm not even sure that when you change allow-external-scripts to yes, the script is launched.

  Issue #7:

	I could not seriously test Issue #6 because:

If you switch to Raw Edition in PackageMaker, change allow-external- scripts value to yes and switch back to Standard edition mode, PackageMaker just crashes.

	Bug ID# 5801805

  Others:

	I could keep on filing bug reports on this one:

"When you choose the script to use for the "Result of Script" requirement, the button should be labeled "Choose" and not "Open" since you do not open the file but choose it."

	"There's no reason to use small controls and widgets in the dialog"

"PackageMaker should be clever enough to set the title value itself when you create the project. It can get on someone's nerves to see this fracking build error claiming that one needs to set a title. Where did my Gigaflops go?"

	...

So what I would suggest in this case is to:

- check if a Javascript test is not good enough

or most preferably:

- forget about using a 10.5 flat package format and instead stick with a 10.4 package format because it will be easier for you to work around the numerous issues in PackageMaker. If you require Mac OS X 10.5 or later for your package, you can restrict this with a VolumeCheck or InstallationCheck script.

My $0.02


_______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: Requirement Check For Initial State
      • From: Adam Halls <email@hidden>
References: 
 >Requirement Check For Initial State (From: Adam Halls <email@hidden>)

  • Prev by Date: Requirement Check For Initial State
  • Next by Date: Tutorial for Integrating PackageMaker into a Xcode build target?
  • Previous by thread: Requirement Check For Initial State
  • Next by thread: Re: Requirement Check For Initial State
  • Index(es):
    • Date
    • Thread