site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com On Mar 15, 2008, at 12:23 AM, Adam Halls wrote: Hi, 1. I have two components that I need to install: Database Engine My Application ---------------------------- #!/bin/sh if [ database_needs_to_be_installed ] then exit 1 else exit 0 fi ---------------------------- if: Result of Script file path: path_to_script Selected Yes Enabled No Issue #1: Issue #2: Bug ID# 5801793 Issue #3: Bug ID# 5801796 Issue #4: Bug ID# 5801798 Issue #5: Bug ID# 5801800 Issue #6: Issue #7: I could not seriously test Issue #6 because: Bug ID# 5801805 Others: I could keep on filing bug reports on this one: "There's no reason to use small controls and widgets in the dialog" ... So what I would suggest in this case is to: - check if a Javascript test is not good enough or most preferably: My $0.02 _______________________________________________ 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... 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. 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: So I select the Database Engine component and click the "Requirements" tab and add a new requirement: 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. 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 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. When you define the script to be executed, the script is not integrated into your package. 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). 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. I'm not even sure that when you change allow-external-scripts to yes, the script is launched. 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. "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." "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?" - 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. This email sent to site_archiver@lists.apple.com