On Oct 8, 2009, at 3:45 PM, Sidney San Martín wrote:
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.
It's possible to create a script-only target. Put one as the first component, and one as the last. It's a hack, and you'll see that target in the GUI when the scripts are run, but it works. I really wish they'd either kept the global pre- and post- or let us define our own actions to extend what's possible in the actions pane.
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
Can't say much about raw editing mode. Haven't used that much. Since I only need to install on 10.5+ for most of my packages I've been using flat packages, and they're structured very differently from bundle packages. They also don't support plugins, so they wouldn't work for you...
I've been pretty happy with the XML files, because they make it easy to write build scripts that manipulate the PM generated files after the fact to make needed changes. For example, there's a bug WRT versions that you need to work around by modifying the files by hand if you're doing automated command line builds. It only affects bundles that are being installed, so it doesn't sound like you need to worry about it...
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?
From your description it sounds like what you need is possible under PM without much customization beyond the plugin you already have. Your level of comfort with the XML files is an important factor if you need to tweak things after the fact though.
There are a number of people on this list using Iceberg, a freeware installation package builder, but I don't know much about it myself. It's at
if you want to take a look.
Kevin
|