site_archiver@lists.apple.com Delivered-To: Installer-dev@lists.apple.com Hi Michael, On Jan 8, 2007, at 1:57 PM, Michael Watson wrote: - Luke -- Michael Watson _______________________________________________ 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/luke%40apple.com _______________________________________________ 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... Using Package Maker 2.1.1 under Tiger, I seem to be unable to build an installer package that will allow a user to install into his or her home directory without authenticating. (That is, without pre/ post-install workarounds.) It appears that Package Maker doesn't actually make use of, say, something like NSFileManager to determine whether or not a user has write access to an area, and then prompt if necessary for authentication. It's using its own internal rule set, which just doesn't seem to be very smart: 1. I have to choose a default installation directory. 2. If I choose "Administrator" or "root" for the authentication option, the user is prompted to authenticate even for places he or she has write access. Unacceptable. 3. If I choose "none" for the authentication option, the user is not prompted for authentication under any circumstance, and thus cannot choose to install to those places that would normally trigger an authentication prompt. Is there a way to solve this, aside from pre/post-install workarounds? No. The installer either installs all files as the user (when authentication is none), or applies the ownership of all of the files from when they were packaged (when authentication is admin or root). There's no support for a hybrid case, except by using scripts as you say. Generally it makes more sense to try to stick to one domain. What are you installing that requires pieces to be installed in both the user *and* the system domain? This email sent to luke@apple.com This email sent to site_archiver@lists.apple.com