site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com On May 11, 2005, at 2:39 AM, Jens Adam wrote: Christopher, thanks for replying quickly. Unfortunately, your answer contradicts my findings. The name matching was what I guessed. But the pre-Tiger installers did not remove items. This irritates me even more. My packages have the same name but different bundle identifiers. According to your explanation, the different identifiers should prevent Tiger from even looking at the package name. The rules for upgrade in Tiger are: Can I overwrite the default behaviour? I assume you could have a hint that says: <array> <string>/*</string> <string>dontobsolete</string> </array> Thanks, Jens _______________________________________________ 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... I combined several package into a meta package to install an application. Later, I made an updater, again combined *.pkg in a *.mpkg. The updater contains changed and new items only. The Installer has always obsoleted files that were in the old package but not the new package, that is how upgrades work. As I wrote in my original message, my updater works in pre-Tiger system versions. That is, items are replaced and added but no item is removed because it is erroneously considered obsolete. It worked in the past with Jaguar and Panther, I verified it today with OS X 10.3.9. The removal happens only with the Tiger installer, so something must have changed. There is no real support for an "updater" package, the only way to do it (and the way Apple does it for Software Updates, unfortunately) is to change the name of the package (for Panther) and the bundle identifier of the package (for Tiger). Note that previous to Tiger, the name of the package is what what made two packages the same (for upgrade behavior). As of Tiger, the Installer uses the bundle identifier. To be compatible with old packages which may not have expected the bundle identifier to be used, the name is also consulted if there are more then one package installed with the same bundle identifier (and if there is no bundle identifier). Well, this is the catch. Because some developers just starting using bundle identifiers (they weren't told otherwise), we had to match on either or. 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. The idea is to switch everyone over to bundle identifiers for Tiger, but since we cannot change packages that have shipped in the past (and since bundle identifiers weren't used in the past), there needs to be a "compatibility" mode For most software projects, this automatic upgrade behavior is what they what, so it is the default behavior. Yes, although I could find no public documentation. Do a search for "Hints.plist" in your receipt directory (find . -name "Hints.plist" - print). You will see a number of Apple packages which use the hints mechanism to prevent obsoletion in some cases. Basically saying don't obsolete anything (although you will have to try that out and see if it works). The problem is, that in the future when you do want upgrade behavior (to remove old files) it will see your "update package" which only contains a few files and you will have a hard time removing all the pieces of the original install on upgrade (if they are truely not part of your product anymore) without writing a script to do it by hand, since the last receipt for a given package is all that sticks around. This worked well on pre-Tiger systems. If the Installer shipped with Tiger is used for the update, all files installed by the original package but not contained in the update package are deleted. The application is completely ruined. The installer log of the updater contains lines talking about the removal of obsolete files. Who decides which files are obsolete? Shouldn’t that be the package author? Is it possible to prevent this kind of damage by other means than * putting everything into an updater, thus making it a full installer? * changing package names, thus damaging the idea of receipts? Please let me know if you would like me to provide my packages for your inspection. Please send me the packages privately (or how to get them) I would like to see why you are not seeing upgrade behavior on Jaguar/ Panther, but are on Tiger. Chris This email sent to site_archiver@lists.apple.com