site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=si3EjOIzrfEIBD3jZDA2fnhizOlett9cNjJbGdF82rObeG352+hVziQZP+9vnlSKvlc7++bbcIExdnC0Sn4tViVHA7uBqNF1TZ3/wZQz/WrrBxlpXfs/k0rcqPnBdiBr8enLOTcGEL1daGWANyi479EHi3PLq0g3M4fSGGxKLD4= ; Thank you. JongAm Park On Nov 13, 2009, at 3:42 PM, Iceberg-Dev wrote: On Nov 13, 2009, at 11:04 PM, JongAm Park wrote: Hello, I noticed a problem with the PackageMaker. _______________________________________________ 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... Hello, while I was preparing a package to show you, I finally found a combination of AppleScript / Shell script and PackageMaker setting. I didn't want to expose any my binary files related to products of my company, so I created a dummy app to install and used same setting. And... because the package is totally new, there is no existing entry in receipt DB. So, it is clearer to figure out what will happen on a customers machine when S/W programs are freshly installed. For others who may have difficulty in doing similar things, I would like to summarize what works and what doesn't work. What doesn't work ================ 1. Adding a login item on a product package setting using AppleScript. ( Open File automator setting. ) 2. Adding a login item using defaults system on a component package setting. This utilizes shell script. What works ========== 1. Adding a login item using AppleScript invoked by shell script on a component package setting. The AppleScript file should be removed by the shell script, if you don't want to leave the AppleScript file which is only for adding an login item. The location of AppleScript file is better to be hard coded. If it uses $1, the location can be somewhere-else from time to time. Then it can't find where the script is. One weird case I noticed what that the installer log said that it returned the location in a installation file itself. This is a major problem of the PackageMaker which confuses a installer build engineer. I know that it can find program execution binaries in a project's build directory, but with some files it can find one in installer package itself. I don't know how to replicate this. I noticed it several times before, but I don't have that kind of installation file anymore. Also, it would be good if there is a setting in PackageMaker to set not to search a certain folders for relocatable setting eventually. If it finds the ones in build directory, it can confuse people at first. ( I was one of them about one year ago. ) The location of an application program to be installed is better to be "non-relocatable". Probably there can be some environment setting which keeps the actual location where the file is to be installed, but I didn't find it. So, for being sure, "non-relocatable" setting with hard coded path in a shell script is better. post-install / post-upgrade / post-flight For Mac OS X 10.5+, post-upgrade/post-flight don't exist. So, post- install should be used. For Mac OS X 10.4, post-install and post-upgrade are used or only the post-flight should be used. post-flight is the last one to be called. Also, it is better to have a clean receipt DB. I noticed that receipt DB was very fragile. Especially on Snow Leopard, I noticed this. Sometimes installation process goes smooth even when a system has broken receipt DB, but sometimes it doesn't. Removing *.pkg files from a Receipt folder is not sufficient. So, it is better to issue "pkgutil --forget <package ID>". On a system with a broken receipt DB, "pkgutil --pkgs" doesn't return a list of installed packages with ID for our interested program. Even without the ID, it works sometimes. I made an installer using the PackageMaker to install an AppleScript app which is in Bundle. Choosing "Application" from Script Editor produces PPC binary. So, to have Universal Binary version, I had to use Application Bundle style. What happens actually is that the app is not installed to / Applicaitons directory. Other Objective-C/Cocoa based apps in the installer package can be installed in the directory except for the AppleScript App Bundle app. So, I tried making an installer which contains only the troubled app, and it still was not installed. I think this is kind of bug in PackageMaker. I filed this using Apple's Bug Report page. Can someone at Apple investigate this? It ID is 7393659 It's not a bug. It's a feature that is seen as a bug by most users because it's opt-out not opt-in. Solution: Uncheck the relocation flag. You can search the list archive to find more information. This email sent to site_archiver@lists.apple.com