site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com On vendredi, septembre 21, 2007, at 09:32 PM, Jack Repenning wrote: On Sep 21, 2007, at 11:46 AM, Peter Bierman wrote: 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... While I agree that this situation makes life hard for the installer, the Mac OS X Installer handles this as well as can be expected. The OS itself installs many many files that overlap between packages. The consequences are that when multiple packages own the same file, upgrading any one of those packages has the potential to replace or remove that file, leaving the other packages in an inconsistent >> state. When you know the circumstances of upgrading, you can work around this issue. For example, with Annette's issue, if she replaces a font that should exist anyway, then system upgrades will update or replace that font as necessary. Sure, I didn't mean to dis the Apple installer. But we're still -- inescapably, so far as I can see -- left with those potential inconsistent states. If for example, Annette cares about this font because she wants to use it (seems a safe guess!), and she wants to use this particular font because its metrics make some tricky form layout work better than any other font (wouldn't surprise me, given her return address and implied product), then a change to the font that altered the layout metrix (a thing outside her control, since she doesn't actually own this font) would be a big deal for her: when half her customers start complaining that the form lays out wrong, she'll have a very hard time figuring out why it fails at all ("works for me"), let alone why it only fails for half her customers. Hmm, I think there's one point that has not been taken into consideration. It's not because a file is not where it has been installed that it's not there. Let's have a look at the case of a Font file. Some utilities lets you disable Fonts by moving them to the Fonts (Disabled). I wrote a tool that does this and other Font tools available for Mac OS X do this too. Maybe Font Book.app does this differently to disable a font. I haven't checked it. Anyway, the fact is that if you assume a Font is not on the System because it's not in /System/Library/Fonts or /Library/Fonts or ~/Library/Fonts, and if this leads you to install it in the Fonts folder in the appropriate domain, then you will be faced with a funny case, where the Font is both enabled and disabled. This may confuse some of the previous mentioned tools and the user (if he/she selected to disable this font in the first place). So if you need to check for the existence of a Font on Mac OS X, don't limit yourself to /Library/Font and don't assume it has not just been moved to a Fonts (Disabled) folder. This email sent to site_archiver@lists.apple.com