Re: packagemaker update problems
Re: packagemaker update problems
- Subject: Re: packagemaker update problems
- From: Bill Coderre <email@hidden>
- Date: Mon, 10 Sep 2007 13:08:41 -0700
So, being the Troy McClure of Apple updaters -- you may remember me
from such updaters as iWeb 1.1 (which made iWeb smaller on disk) or
iPhoto 6.0.3 (which had Combo and Delta versions). I'll be giving you
some helpful tips on installer behavior today...
When the installer is going to install, it looks for a receipt with
the same name as the current package about to be installed.
If there is none, it installs the files in the BOM (if there's a
bundle with a newer version as noted in BundleVersions.plist, it will
skip that bundle, and put a note in the log). The Install button will
be titled "Install."
If there IS a receipt with the same name, and the receipt has a
version (noted in IFMajorVersion and IFMinorVersion of the
Info.plist) that is newer than the one being installed, the installer
prevents installation with an error.
If not, the installer goes into "upgrade mode." The Install button
will be titled "Upgrade." Also, the installer will find all the files/
bundles in the receipt that are not in the package being installed,
and "obsolete" them (delete them) during installation.
So the name you choose is particularly important.
And here's my policy on installer names and IDs.
If an installer contains the complete software package, I call it a
"full installer" and give it a name like iMovie.pkg.
If an installer contains a partial set of software, I call it an
"update installer" and give it a name like iMovie_701.pkg.
At the risk of offending people by saying this is a "good" scheme,
let's just say it seems to work OK for me. Note that if there ARE
files to be gotten rid of, I have to do that with an additional
script. But I have a script to do that, and the list is simple enough
to generate during build.
Hope This Helps.
On Sep 10, 2007, at 11:19 AM, Peter Bierman wrote:
The behavior you're confused about is actually the basis of the
existence of the installer as opposed to just using tar or zip.
When the installer detects that a different (not just older)
version of the "same package" is already installed, it will remove
any files that were installed by the previous version that are no
longer part of the new version.
Lying to the installer by hacking the BOM is a very bad idea.
-pmb
At 10:40 AM -0500 9/10/07, Steve Stockman wrote:
Does your updater have the same name and bundle ID as the full
installer?
I'm not sure whether this behavior is actually documented
anywhere, but
we've found that when you install a new package that has the same
name as an
old package already in /Library/Receipts, if the .bom file in the old
package lists any installed files that do not exist in the new
package's
.bom file, the Installer will often delete such files (presumably
under the
assumption that the files are obsolete).
The solution was simple: Build both the full installer and the
updater, and
then replace the updater's .bom with a copy of the full
installer's. And
the Installer never seems to complain about files named in
the .bom that
don't exist in the archive.
----------------------------------
Steve Stockman
Software Architect
Consumer Products - Macintosh
Symantec Corporation
www.symantec.com ----------------------------------
From: Robert Carroll <email@hidden>
Date: Sun, 9 Sep 2007 23:50:29 -0400
To: <email@hidden>
Subject: packagemaker update problems
Thanks for your reply Stephane.
One cause of the problem with the updater has been somewhat
identified.
The full installer of my application bundle includes a folder inside
"Resources" with a set of sound files.
Since these files do not change with the updates, I do not include
them in
the updater package.
In testing on my machines, if I don't at least leave the empty
"Sounds"
folder in the Resources folder, the update
appears to delete this folder and its contents.
Leaving the directory structure in place, correctly leaves the
required
sound files post update on my machine, but seems to
still remove these files on some user's machines. I am trying to
verify
this.
On Sep 8, 2007, at 3:05 PM, email@hidden
wrote:
The updater is set up to replace the app file in the MacOS
folder of
the client's currently installed version.
It shouldn't touch any other files in the same package (ie.
resource
files or the encrypted registration info) and doesn't not
replace or change anything elsewhere on the computer.
Is this a known issue? Is there a safer and more reliable way to
accomplish this kind of update?
Regarding the permissions issues:
- Which authorization are you requiring?
I'm requiring administrator privileges to run either the installer
or the
updater. The files in the package mostly show me as the owner,
read-only privileges
or read-execute for
others. Is it normal to leave myself as the owner, or more common
to set
this as root or something else?
The resources folder must have read-write privileges for everyone,
since the
app will write encrypted registration data
to this folder on its first run. It's possible this would be
better if it
was in the application support folder, but I prefer the concealed
location in the app package.
- Do you use a default location that is not '/'?
No.
- Which OS version is the update run on when it does not work?
Regarding the "does not runt at all" issue:
- Do you take into account the fact that the application may
have been
moved by the customer?
- Do you use a Locator to look for the location of the application?
This is a valid concern. I don't currently check the installed file
location, which would obviously foil the update.
>
- Do you use Resource Fork for resources in your application? If
so, do
you split fork when you're creating the packages?
I'm not using resource forks, however the sound files still have
resource
fork data. I would like to confirm that
this data is not essential. At the moment the resource fork data
is being
preserved in the installer & updater pkgs.
best wishes,
Robert Carroll
RSM Records
Toronto
http://www.rsmrecords.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com
This email sent to email@hidden
_______________________________________________
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
_______________________________________________
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