On Feb 10, 2006, at 12:13 PM, Aaron London wrote: The best way to do this, in my experience, is to process the receipt for the given package at install time (e.g. from a postflight script). It is a shame that Apple refuses to accept reality and give us the uninstall functionality we need. BTW, I've already submitted an uninstall feature request (radar 4409862) which Apple has closed as a duplicate.
Apple is extremely aware of the desire and need for ways to find out what was installed when, where, and by which installation packages.
Uninstall is one facet of that. Package management is, you could say, the "think big" feature that includes all of this.
The current receipt mechanisms have bugs, and that's a big reason that they don't get documented and supported. Also, the receipts contain a lot of stuff that is probably useless, and some people have complained that they think that the current receipts waste a lot of space. Apple would rather bury these receipt formats and replace them with something more applicable to the overarching needs.
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.
Please try to think kindly of the people working on the Installer. They share your pain and frustration.
Now, let me mention how iLife ’06 approached this problem.
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 hope this helps all of you at least a little.
|