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: Bill Coderre <email@hidden>
- Date: Fri, 28 May 2010 17:45:18 -0700
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