PackageMaker: Set Permissions on Applications Subdirectory

Question

Hello everyone --
I'm new to the Apple package making process and running into some interesting issues. I developed a series of scripts wrapped into Automator applications which I want to deploy to a subdirectory of Applications (ex /Applications/Mypp/). I have each component Destination set to this path. One of the components in the package is itself an Automator application which performs some auxiliary functions. This auxiliary application is triggered to run after all components are deployed to the /Applications/MyApp directory via a Postinstall "Open File" action.
Issue: The package does everything I expect when deploying to Leopard systems either locally (double-click the pkg file and install manually) or remotely (via ARD). However, the package does NOT behave as expected when deploying to a Snow Leopard system. The specific issue is that the package is creating the subdirectory in Applications with unexpected ownership and permissions; ownership: [alternate local admin]:wheel, permissions 700. With these permissions, the auxiliary applications do not have permission to execute. The auxiliary apps and scripts are copied into the /Applications/MyApp subdirectory with the chmod permissions I set in PackageMaker.
I believe the way out of this debacle is to use a Preinstall script. I tried implementing a Preinstall script by writing a Bash script (named preflight, set chmod ug+x) containing the following:
#!/bin/bash
/bin/mkdir /Applications/MyApp
/bin/chmod 775 /Applications/MyApp
The script Destination is /private/tmp, is copied there successfully, but is not executing as expected.
I think that the solution to this problem is somewhere in the nuance of the Preinstall or preflight process, but I'm unable to figure this out.
I am using PackageMaker v3.0.3 on OS X Server 10.5.8 to build the package. Target systems are Snow Leopard 10.6.4.
Any clues? I know I've seen some people complaining about PackageMaker, but I refuse to give up and use a .dmg unless absolutely necessary.

Answer 1

mdecheser wrote:
I'm new to the Apple package making process and running into some interesting issues. I developed a series of scripts wrapped into Automator applications which I want to deploy to a subdirectory of Applications (ex /Applications/Mypp/). I have each component Destination set to this path.
Set the component destination to just /Applications and have MyApp as part of your component. Then it should honor whatever permissions you have set in your source.
Any clues? I know I've seen some people complaining about PackageMaker, but I refuse to give up and use a .dmg unless absolutely necessary.
I wouldn't consider that any admission of defeat. Apple itself has stopped recommending the use of Package Maker. http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/S oftwareDistribution/Overview/Overview.html
The nature and structure of your product determine the install experience you can provide to its
users. If your product is a self-contained application (one that doesn’t need to install components
at different locations in the file system), you can distribute it as a single file or folder. Users then
can drag the product from its container or delivery vehicle to a location of their choice in their file
systems. This type of installation process is called manual install. This is the preferred method of
delivering applications to Mac OS X users.
However, there are situations that require more complex products. For example, some applications
require the presence of shared resources such as frameworks or fonts, which, in general, reside at
/Library/Frameworks and /Library/Fonts, respectively. Each item that resides at a distinct location
on the file system is known as a component. To make it easy for users to install a multicomponent
product, instead of making users place each component in the appropriate location you develop an
appealing install that frees users from that tedious and error-prone task. To that end, the Installer
application (/Applications/Utilities) uses a simple interface to guide users through the process of
installing multicomponent products. This type of installation process is known as a managed
install.
You use PackageMaker (/Developer/Applications/Utilities) to develop a managed install.