site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com On dimanche, février 12, 2006, at 01:32 AM, Bill Coderre wrote: Now, let me mention how iLife ’06 approached this problem. Solution: Delete the receipts in a postflight script when needed * Prevent installing some 10.2 format package over 10.1 package format Solution: Delete the receipts in a postflight script Solution: Delete the receipt after installation Solution: Upgrade to another major OS version. So, please be crual, just kill the receipts thing. However, ideally, receipts shall be replaced by a database IMHO. My $0.02 _______________________________________________ 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... [...]The installer's #1 client, however, is the system software installer. If that breaks, almost the entire company sits on hands until it gets fixed. All of these things have conspired to cause extreme frustration inside and outside Apple. Apple employees are not allowed to predict the future. (Well, MOST Apple employees.) Therefore, it's forbidden to say "we plan to fix this in the next release," or even, "we're working on it, and it might get into the next release." Especially on a public mailing list. Maybe only Oracle's employees are allowed to predict the future. But this is so uncertain... Please try to think kindly of the people working on the Installer. They share your pain and frustration. In iLife ’06, most of the apps allow their "rich content" (Themes for iMovie and iDVD, Instruments, Loops. Demo Songs, etc for GarageBand) to be installed in user-specified locations. So how do the iLife apps know where the media got installed? The installer packages have postflight scripts that write simple plist files in known locations that specify the locations. Very simple "one page of code" stuff, immune to the vagaries of the installer. You,  as installer authors, can look at that code as "inspiration." It is unsupported, and it is not guaranteed to work in your installer or application. If you use it, and it breaks, you get to fix it. Not Apple. Looking over the code, though, I think you might be better off looking at the plist files, and writing your own code to manage them. I think the code is pretty clear, but it uses some helper utilities that are not guaranteed to be on the user's system, and which might present challenges to ship in your installer packages. I think you are missing one point: iLife 06 is not free to ADC members (paid members included [contrary to what Microsoft would do in such a case with the MSDN program]). So basically, you are suggesting to pay $79 to know how to do one thing. Maybe it could be hosted as a technote since it would avoid people paying $79 or doing piracy to just look at it. Regarding receipts, the more it goes, the more it looks like to be a problem in itself: 1) This solution is incompatible with Universal Binaries if you need to support 10.2 (and contrary to most of the software supported by Apple, some people do need to support 10.2) 2) Versioning supports: with each release of the OS, the way the version is computed is changing. And in most cases, it's causing more issues that anything: * Prevent installing some components of a metapackage because one component is tool old when compared with the receipts. 3) Permissions issues: From what I heard, the latest package for iTunes 6.0.2 is preventing permissions reparation. 4) Security issues: As far as I know, receipts (at least Apple's ones) are being used to know the file permissions, owners and groups to set for a file/folder. As a side effect, whenever you repair your permissions on Mac OS X 10.X (where X is 2 I think), a security flaw is being re-opened on one binary (a setuid flag is set back). This email sent to site_archiver@lists.apple.com