Re: Tiger’s Installer deletes files during an update
Re: Tiger’s Installer deletes files during an update
- Subject: Re: Tiger’s Installer deletes files during an update
- From: Christopher Ryan <email@hidden>
- Date: Wed, 11 May 2005 08:07:32 -0700
On May 11, 2005, at 2:39 AM, Jens Adam wrote:
Christopher,
thanks for replying quickly. Unfortunately, your answer contradicts my
findings.
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).
The name matching was what I guessed. But the pre-Tiger installers did
not remove items.
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).
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.
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.
The rules for upgrade in Tiger are:
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.
Can I overwrite the default behaviour?
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.
I assume you could have a hint that says:
<array>
<string>/*</string>
<string>dontobsolete</string>
</array>
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.
Thanks,
Chris
Jens
_______________________________________________
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