Re: Install file only if it exists on target?
Re: Install file only if it exists on target?
- Subject: Re: Install file only if it exists on target?
- From: "Andrew Peckover" <email@hidden>
- Date: Mon, 31 May 2010 09:31:34 -0700
Thank you, Bill and Greg, for both of your tips
I think the best option is to use the post-flight script method. This seems
very simple. If you have a moment, can you just confirm if the following
would be an acceptable way to do it:
1. Install all files to /Applications/MyProgram/TempFolder, then run a
post-flight shell script.
2. The script moves each file from the tempfolder to the destination
folder, if a file with the same name already exists there.
3. The TempFolder is deleted.
---
This is sort of a moot point, but I'm confused about why you say my original
package should have been a metapackage. I thought all packages created with
PM are metapackages using PM version 3.0.3. I think it may have worked
differently with earlier versions of PM, but I have never used an earlier
version. In any case, there are a large number of collections of files,
which aren't necessarily known at the time of making the initial program
installer, so that method wouldn't work too well.
Thanks,
Andrew
----- Original Message -----
From: "Bill Coderre" <email@hidden>
To: "Andrew Peckover" <email@hidden>
Cc: <email@hidden>
Sent: Friday, May 28, 2010 5:45 PM
Subject: Re: Install file only if it exists on target?
On May 28, 2010, at 3:05 PM, Andrew Peckover wrote:
Is there a way that I can have a file only get installed if it is already
present on the user's system? I know that I can set a requirement for a
choice (only install if a particular file exists on target), however I
need to do this for hundreds of files.
The only way I can think of doing it is to create hundreds of different
choices. Which I can do with some time, but then hundreds of receipts
get put on the user's system which seems a little "unprofessional"
Does anyone know a better way? I would be very grateful for any tips...
To answer your questions in reverse order:
2) "Hundreds of receipts" is not a great idea, but if you end up having
(say) a dozen, then don't worry. Almost no users go looking through
/Library/Receipts, and if you use "flat" packaging, the receipts are
stored in a database, not a folder full of files. Users will not complain
about this. Don't worry.
1) Mac OS X installer does not provide "update only if existing"
functionality. Original Mac OS had that, but it also required that EVERY
SINGLE FILE in an installer had three separate entries in a
pseudo-database. On Mac OS X, where a typical app might have 10,000 files,
a simpler model was necessary.
The way I like to think of Mac OS X installation is this:
Installation is like an enhanced Unix "tar" wrapped with preflight and
postflight scripts, for cleaning up.
Note that "enhanced" includes a number of details, but most importantly:
a) in SOME cases, files might not be installed even if they are in the
archive. To a first approximation, Installer will often attempt not to
"downgrade" bundles, based on bundle version information.
b) owner/group/permissions are stored in the archive, and almost always
imposed on the target
c) There are enhancements to the archives to allow installation of, for
instance, symlinks, which technically aren't files.
Here's what many would say is the "best" option:
Let's assume for the moment that although there are hundreds of individual
files that need to be updated only if existing, they group into a small
number of logical collections, for example:
MyGreatAppBeginner.app
MyGreatAppPro.app
MyExtraPlugin1
MyExtraPlugin2
etc.
Now you make an installer package for each of these, have each package
install only if the existing stuff is there, and then put a metapackage
around it that allows the install if ANY of the subpackages is needed.
Note that you would NOT have packages like this:
BeginnerOnly
Beginner&PL1
Beginner&PL2
Beginner&PL1&PL2
ProOnly
etc.
You would have this:
AppUpdate
ProUpdate
PL1Update
PL2Update
A Second Option:
Install everything into a "holding tank" and then run a postflight script
to do the appropriate updating. Or write your own "app" to do it. (You
could write an "app" in AppleScript or even as some kind of shell script.)
_______________________________________________
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