Re: installer application ?
Re: installer application ?
- Subject: Re: installer application ?
- From: Sherm Pendley <email@hidden>
- Date: Fri, 13 Jun 2003 00:16:59 -0400
On Thursday, June 12, 2003, at 07:15 PM, Marc Weil wrote:
Does anybody know of a good tutorial or website or SOMETHING that is out
there for showing people how to use this program?
In a nutshell, it goes like this:
You create a "Root Directory" that contains everything in your package.
Within this directory, everything you want to install must be in its
proper location relative to everything else. So, for example, if you
want to install an app and some support files:
1. Create a directory called "/Users/(your login name)/MyApp". This is
the "Root Directory."
2. Under that directory, create an "Applications" directory and a
"Library/Application Support" directory, and copy your app and support
files into them.
You can also create, if you want, a "Package Resources" directory. This
should somewhere outside of the package "Root Directory," not under it.
Several files can go here:
1. If a file named welcome.(txt/html/rtf/rtfd) is found here, it will be
displayed in the installer's opening window.
2. If a file named ReadMe.(txt/html/rtf/rtfd) is found, it will be shown
in a sheet that must be dismissed before installation can proceed.
3. Finally, if there is a License.(txt/html/rtf/rtfd) file, it will be
shown in a sheet with agree/disagree buttons. Clicking disagree will
cancel the installation, and agreeing to the license will allow it to
continue.
You can also create localized versions of these files. Just create
English.lproj, French.lproj, Klingon.lproj and other subdirectories as
appropriate under the package resources directory, and store the
localized copies of the above files in them.
Finally, you can also put pre- and post- install shell scripts in the
resource directory. They can be any type of script - Bourne shell, Perl,
Python (for 10.2+), or whatever.
1. If the user is upgrading this package - that is, if there is a
receipt in the receipts directory - then scripts named
"packageName.pre_upgrade" and "packageName.post_upgrade" will be run
before and after the archive is unpacked, respectively.
2. For packages that have not been installed before,
"packageName.pre_install" and "packageName.post_install" scripts are
looked for.
In PackageMaker, going from top to bottom, the options are:
1. The "Package Root Directory" and "Package Resources Directory" are
the directories mentioned above.
2. I haven't experimented with the "Include Root Directory" checkbox,
but I *think* it works with the "Default Location" path - see below.
3. The "Package Title", "Package Version", and "Package Description"
entries are fairly obvious.
4. I don't know what the "Delete Warning" option does. (Anyone who does,
please feel free to enlighten me...)
5. The "Default Location" is where the contents of your "Package Root
Directory" are installed. So, in the above example, you'd specify "/"
for this, so your app would be installed in "/Applications", and its
support files in "/Library/Application Support". As I said above, I
*think* that the "Include Root Directory" checkbox modifies this
behavior, prepending either the name of the root directory or its full
path to whatever you enter here to determine the final installation
location of your files.
6. The "Needs Authorization" option determines whether an admin password
will be requested prior to installing your package. If you're installing
files into system areas - which includes /Applications and /Library -
you'll need to enable this.
7. The "Required" option is used when creating metapackages, which are
essentially packages of packages. If this option is not checked for a
subpackage, then the user opt not to install it by de-select it from the
package list. If it *is* checked, the package is selected by default and
de-selection is disabled.
8. "Relocatable" allows the user to change the "Default Location" you've
specified. Whatever location the user chooses, the files found in the
"Package Root Directory" are installed in the same positions relative to
one another. That is, if you've specified "/" as the default, and the
user instead chooses his home directory, the above files would be
installed in "~/Applications" and "~/Library/Application Support".
9. "Requires reboot" is just what it says - if it's selected, the user
will be required to reboot his system after installing your package.
Beware of this option, though - if you choose it, the discussion-board
trolls will attack en masse.
10. "Use UserMask" is used with the "Needs Authorization" flag above,
and affects the ownership of the installed files. If it's selected, the
admin user specified in the authentication dialog will own the files;
otherwise, the ownership that was in effect when the package was created
will remain. The latter is generally only used for creating packages to
be installed on local machines that share the same NetInfo login
database. (If you need more detailed control over file ownership, use a
post_install script and the chown command.)
11. The "Overwrite Permissions" options, if selected, will replace the
permissions of any directories touched with the permissions of the
corresponding directories in your package. To continue the above
example, if this is selected, and the "Applications" subdirectory is
world-writable, then the user's main "/Applications" directory would
likewise be world-writable after installing your package.
12. I'm not certain of the purpose of the "Install Fat" option. With
multiple supported architectures and "fat" binaries a thing of the past,
the only "Fat" installation I can think of would be one that installs
all of the available localized resources vs. allowing the user to select
which ones to install.
13. Last but not least, the "Compress package" does just that - it
compress the .pkg file. I can't think of any case where this would be a
bad thing - frankly, I don't even know why it's optional, even though it
is, at least, enabled by default.
Okay, so it's a *big* nutshell. Could it be from a... wait for it...
cocoa-nut? (Boo! Hiss!)
It's worth noting that every last bit of the above information comes
from the "PackageMaker.help" file that was installed on my machine with
the 10.1 developer tools. With all of the complaints I'm hearing about a
lack of documentation, I wonder if Apple somehow forgot to include this
file with 10.2. :-(
sherm--
The wise programmer is told about Tao and follows it. The average
programmer is told about Tao and searches for it. The foolish programmer
is told about Tao and laughs at it.
If it were not for laughter, there would be no Tao.
-- The Tao of Programming
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.