site_archiver@lists.apple.com Delivered-To: Installer-dev@lists.apple.com The rules for matching are as follows: Of course you could also specify Which says not to obsolete anything. Chris Regards, Phill _______________________________________________ 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... This email sent to site_archiver@lists.apple.com The dependency on CFBundleIdentifier is on purpose. The Installer has switched to using an identifier (in this case the CFBundleIdentifier) for the upgrade logic. The name is to fragile and caused too many collisions. Imagine the scenario where two developers create a package of the same name (MusicApp.pkg). The results would be tragic. This created the need for the transition to an identifier. We still use the names in the case where CFBundleIdentifiers are not specified. If the name and identifier of a package matches only 1 receipt, then it uses that receipt for upgrades. If not, then check to see if any 1 receipt matches the package identifier, if so, use that receipt for upgrades. If not, then check to see if there is 1 package with the same name, if so, use that receipt for upgrades. Otherwise, it is a clean install. You are trying to make an upgrade only package. This concept doesn't officially exist (although it should and hopefully will in the future). To do what you are doing, you can use the Hints mechanism, however. Although I have found no Public documentation on such, this is how you use "hints" to do what you want. Check out some of the Apple receipts, they use a file named "Hints.plist" to specify a "hint" about a given file. In your Hints file you can specify that you do not want to obsolete (delete) a path (or a group of paths). Here is the example of a Hints.plist file that should be placed in the Resources directory of a package: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http:// www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <array> <array> <string>/Applications/My.app/Contents/Resources/English.lproj*</ string> <string>dontobsolete</string> </array> <array> <string>/Applications/My.app/Contents/Resources/French.lproj*</string> <string>dontobsolete</string> </array> </array> </plist> This says when installing, never obsolete the contents of the English and French .lproj. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http:// www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <array> <array> <string>/*</string> <string>dontobsolete</string> </array> </array> </plist> Remember, when you start playing that game, the day you want to actually obsolete files when you have a newer version of the app, you will need to do it via a script. Again, this limitation is known and we hope to have something better in the future. I used to believe that Installer made its "install vs upgrade" decision solely on whether there was a package of the same name in /Library/Receipts. To quote from the relevant page: "Installer uses the presence or absence of a receipt on the installation volume to determine whether an installation is an install or an upgrade. That is, Installer assumes software is being installed for the first time if there is no receipt with the same name as the package being installed. If there is such a receipt, the installation is an upgrade." To that end, whenever I have built an updater I have made sure that the installer package has always had a different name from what has gone before. However, when testing an updater package last week, I was surprised to find that even though (a) my package had a name of the form "product_1.2.3_updater.pkg" and (b) there was no receipt of that name in /Library/Receipts, the Installer presented me with the "Upgrade" button. There was a receipt with the name "product_1.2.2_updater.pkg". If I removed that from /Library/Receipts, Installer presented me with the "Install" button. If I returned "product_1.2.2_updater.pkg" to /Library/Receipt, Installer went back to "Upgrade". If I renamed "product_1.2.2_updater.pkg" to "Fred.pkg", Installer still presented me with "Upgrade". By trial and error, I reached the conclusion that the name of the receipt didn't matter but that Installer was looking at the value of CFBundleIdentifier in the packages' Info.plists. In the past, I have set the value of CFBundleIdentifier to be the same as the identifier of the application that the package is updating (previously via the PackageMaker GUI but these days by the -i parameter passed to the command-line packagemaker). By changing the value of CFBundleIdentifier to embed the version number (eg com.company.product_1.2.3_updater), I have been able to overcome this problem so that packages that are meant to update an existing application always show "Install", thereby only ever adding or replacing files (which is all my updater packages contain) and never attempting to delete any files on the assumption that non-presence in the updater package implies "no longer needed" as opposed to "no change". Has anyone else encountered this apparent dependence on CFBundleIdentifier or am I missing something? smime.p7s