Lists

Terms and Conditions
Lists hosted on this site
Email the Postmaster
Tips for posting to public mailing lists

Fed up with PackageMaker, any advice?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fed up with PackageMaker, any advice?

Subject: Fed up with PackageMaker, any advice?
From: Sidney San Martín <email@hidden>
Date: Thu, 8 Oct 2009 18:45:39 -0400

I have been poking around inside installer packages for years. They always looked simple and straightforward: *Check scripts run, plugins run, pre* scripts run, files are copied and permissions are set, then post* scripts run. Simple. So I thought it would be painless to put together an installer package for a product of my own. The process turning out to be surprisingly headachy. Can any of you give some advice on taming this beast?

Here's what I want to do: 1. Run a plugin to collect some setup information from the user (it's built) 2. Copy some files to a company-specific folder in Application Support 3. Copy a launchd.plist to /Library/LaunchDaemons 4. If running on >=10.5, copy a launchd.plist to /Library/LaunchAgents 5. Run a postflight script to do initialization (including launching a helper executable to add a global login item if running on <10.5)

I also want to be able to build the installer from an XCode project (which will depend on its components' products) so I can build the product in full, in debug or release config, with one click and spit out an installer package (or, eventually, a disk image with a package inside it).

Right now, I'm not at all close to that goal. I started out thinking that a simple package with a root of / containing the desired hierarchy was the most straightforward design, but saw a stern warning against that in the docs. It looks like the only option is a package containing subpackages (four of 'em) for each component, with appropriate roots. I have no idea where to put my pre/postflight scripts, though. Apparently they can only be set for the subpackages, and there's a note in the docs stating "In Mac OS X v10.5 clients, the only install operations available are preinstall and postinstall." What the heck does that mean? What about preflight, postflight, preupgrade, and postupgrade? If only preinstall and postinstall are available, does that mean they'll be run every time? Either way, I don't NEED any of those advanced options, just a postflight guaranteed to run at the very end. PackageMaker itself seems to be able to create pre and postflight scripts (Actions tab), but there's no way to specify my own.

PackageMaker is specifying everything with absolute paths (great, since this project may be moving around) and when I try to add a couple of binaries to the package's Resources folder through Raw Editing Mode, it includes them non-executable. I have also had PackageMaker try to munge my project a couple of times, including resetting all the permissions to defaults and spontaneously requiring logout on all my components. I'm fed up, and I'm also scared of the big mess of XML files that currently defines the installer. I would much

What would ya'll suggest as far as implementing this (or any) package in the simplest and most useful (read: easy to modify, easy to script, less likely to spontaneously break) way? _______________________________________________ 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: Fed up with PackageMaker, any advice? From: Iceberg-Dev <email@hidden> Re: Fed up with PackageMaker, any advice? From: Kevin Brock <email@hidden> Prev by Date: Re: Package Maker ownership issues Next by Date: Conditionally build different versions of a package? Previous by thread: Re: Problems creating "complex" installation Next by thread: Re: Fed up with PackageMaker, any advice? Index(es): Date Thread