On Mar 17, 2010, at 3:38 AM, Sravana Kumar wrote:
Here in component pkg i need to identify in which distribution package it is running and do some logic some thing like creating a file based on the distribution package. This logic should be inside my component package's preinstall and postinstall.
Can this be done ?
It can be done, but it is probably not a good idea, because schools and businesses repackage installer packages into bigger metapackages all the time.
When they do, your install package won't get the right stuff passed to it, so your installer won't work "the same" -- and you'll get support calls. (Read what people write online about some companies' installers, and you can get an idea of how they might react to yours.)
On Mac, the mindset is to view the installer as a simple copying of files out of an archive into place, with an enhancement so, e.g., application programs are not downgraded to an older version. (Installer.app uses the Mac programming concept of "bundle versions" to prevent downgrading.)
This is very much the opposite of the Windows installer mindset, where any installer must also be an uninstaller, unload and reload drivers, "phone home" with registration, automatically spool a copy of the manual to the printer, etc, etc, etc.
It is also very common for a senior company official to say "The Mac installer MUST BE THE SAME AS the Windows installer." Often I'm asked why our installer does not shut down all other programs, completely take over the screen, etc. etc.
Well, Mac is a very different ecosystem, emphasizing simplicity. (Some would say over-emphasizing.) The code being installed is definitely different between Mac and Windows, the code DOING the installation is definitely different between Mac and Windows, why shouldn't the installer LOOK different?
There are two common situations which cause companies to ship complex installers:
1) They are doing work the program should do itself (eg. fixing preference files). Since your program has to deal with this situation anyway (because users drag-copy apps), why not have it just do the work?
2) They are installing different things on different systems. A common example is to install a Spotlight indexer on 10.5 and later systems. In this case, the preferred solution is to create multiple installation packages and use a distribution metapackage to choose which packages to install.
(I am sure people will suggest other cases, and perhaps common solutions.)
Yes, there are extenuating circumstances, always. But please try to keep installers as simple as possible.
The Point (finally!): WHY do you need to do this? Can you possibly avoid it? If you can explain, maybe we can suggest a different approach.
(It also helps the Installer core team figure out what features are needed.)