Re: Installer project directory clarifications
Re: Installer project directory clarifications
- Subject: Re: Installer project directory clarifications
- From: Mike <email@hidden>
- Date: Fri, 13 Apr 2007 15:57:04 -0700
Sorry about that last post. I hit the Enter key.
To continue:
mpkgBundle = [ NSBundle bundleForClass:[ DeletePane class ] ];
DeletePane being my subclass to the InstallerPlugin class.
This does indeed give me the bundle to my plugin so if the manual path
munging is the way to go, then this will work.
Thanks,
Mike
Stéphane Sudre wrote:
On dimanche, mars 25, 2007, at 06:20 PM, Mike wrote:
I want to make a single-package installer that contains all my
product's files but I also want to be able to have that package be
deliverable in a Managed Install via Apple Remote Desktop 3.
The Software Delivery Guide is a little unclear as to exactly which
installer packages can and cannot be delivered via this method.
In the fourth chapter it says "Packages contain a product or a product
components", but then later on page 31 the directory hierarchy appears
to require a separate "component" directory for each component in the
install. What if I only want one package but multiple component
directories in that package?
So my two questions are:
1) What is the proper directory hierarchy for a single project
directory full of a variety of product files for a single package and
2) is the directory hierarchy listed on page 31 mandatory - that is,
does the installer actually read the directory hierarchy and then
execute the other items such as "extras" at runtime?
The proper directory hierarchy is the one you choose after having
considered your needs. Basically, you have 2 possible roads:
- (I1) put everything in one package
- (I2) put different components in different package.
I1 is the simplest and most common solution.
I2 might be used in the following cases (the list is not exhaustive):
- your product uses some components that are shared with other products.
You then may want to group the shared components in a different package
to be able to update them independently. (Example: you use some shared
libraries or you need other components to be installed and they are
already distributed as a package).
- some of the components of your products may not be installed if some
requirements are not satisfied. Or you have different versions of a
component and you need to install one or the other depending on some
requirements. (Example: Kernel Extensions for < 10.4 and >=10.4).
- some components are not mandatory and you would like to let the user
decide whether these components needs to be installed or not. (Example:
localizations, examples, goodies, etc.)
But there's really no interest in creating a package per raw components
(application, associated frameworks, Application Support sub folder,
etc...)
My 0.01503€
_______________________________________________
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