Install/Upgrade depends on CFBundleIdentifier?
Install/Upgrade depends on CFBundleIdentifier?
- Subject: Install/Upgrade depends on CFBundleIdentifier?
- From: Phill Kelley <email@hidden>
- Date: Wed, 5 Oct 2005 22:28:20 +1000
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?
Regards, Phill
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden