Re: Install/Upgrade depends on CFBundleIdentifier?
Re: Install/Upgrade depends on CFBundleIdentifier?
- Subject: Re: Install/Upgrade depends on CFBundleIdentifier?
- From: Christopher Ryan <email@hidden>
- Date: Wed, 5 Oct 2005 07:38:57 -0700
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.
The rules for matching are as follows:
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.
Of course you could also specify
<?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>
Which says not to obsolete anything.
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.
Chris
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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