My name is Jack Matthew and I'm the Manager of the Installation and Set Up team at Apple and we're responsible for several things. The installer obviously from the name, but also set up assistant which is the first thing after you buy a new Mac and it asks you for your name and sets up your first user account. Also software update for Mac and Windows and disk utility and a few other things.

So, what are we going to talk about today? We're going to talk about the best strategy for delivering your application on Mac OS X and that may be in the disk image and it may be the a package and we're going to talk about PackageMaker which is our tool for creating those packages and finally we're going to talk about some of the new features in Leopard for the Apple installer and packages. And we've divided this up into three segments and to talk about the first, which is choosing a strategy. going to invite Luke Bellandi, who is our lea engineer on the OS installer for Mac OS X. Take it away Luke.

All right, thanks Jack. So when you're distributing your software, you've got a couple of different options and one of the most important things to remember is that first impressions count. While this isn't the first experience your user's going to have with your software, it is the first experience they're going to have with your product. So you want your installation to be simple, fast and pleasant.

One of the things you need to consider when considering a delivery vehicle for your users, is their expertise level with computers in general, are you working with sort of a novice computer base, user base, more expert user base or for example for a product like iTunes, a really wide range of expertise.

Also, are these people that are familiar with the Mac platform? I know a lot of you are Windows developers who are new to the Mac platform, so you have a lot of familiarity with programming and computers in general, but you're not maybe completely clued in to the specifics of where everything's located on the Mac, things like that.

The second thing to consider when assessing what kind of delivery vehicle to use is the content that you're installing. How many items are you installing? Is it just a single application? Do you have additional documentation? Other media, fonts, graphics, audio? Where do those items live in the file system? For example, if you're installing a kernel extension because you're distributing a new piece of audio hardware, you'll need to have elevated privileges to be able to install that kernel extension.

How do you manage that? And lastly, does the user system have to meet certain criteria in order for the software to be installed? Are you using Tiger APIs and therefore do you want to lock out users from installing on Panther? So, taking those two things into consideration, you've got two options for delivering your software, disk images and packages.

So how do you know which method to use? Well, disk images lend themselves to a drag-and-drop install experience. You've got an application in a disk image window, the user drags it onto their desktop or into their applications folder, the install is finished. This is an installation method that you can consider if your software is sufficiently contained, self contained and your user base would prefer a drag-and-drop install. Otherwise you can use a package-based install. One thing though is that it is never a bad idea to use a package-based install. It's always okay.

Here's an example of a drag-install by a disk image. It's a single item, one application. We've got a background graphic giving some instructions as to how the user needs to perform the install. The two icons on there, we've got the application MarsEdit and then we've actually got a SIM link to the applications folder on the user's system. So the user doesn't even have to drag out of this window to perform the install.

The background picture also have some clear instructions. One thing to note is that the instructions in this case are in English and if you're distributing an application with multiple localizations, having text instructions in the background may not be the right solution. And this leverages the finder. So that's a finder window that has the disk image open in it.

The other option is a package-based install. Here we've got a screen shot of an iWork '06 install. If any of you have installed iWork, Final Cut Studio 2, iLife on your Mac, you're probably familiar with the Mac installer and this leverage is Installer.app. So those are some of the things to keep in mind when you're trying to decide how to distribute your software to customers. So let's look at the first of the two. Disk images.

So what's the user experience like downloading a disk image? Well, step one they download the disk image. Step two they open it. And step three they drag the contents onto their system. One thing I mentioned earlier is that you may want to consider that having a specific language in your background picture, could pose a problem. What the folk at Firefox have done is made a localization free background picture that still instructs the user on how to install their software. Pretty cool.

So why disk images? A disk image is, it's essentially a single file that is a logical disk so all it ends up being is a compressed file. So why use a disk image over a tar file or a zip file? Well let's take a look at some of the advantages and disadvantages.

Compressed files offer cross-platform support, disk images don't. For most of you, we're thinking you're probably going to be installing applications, drivers, things that are binaries that are specific to Mac OS X and so that cross-platform capabilities are probably less interesting to you. For things like media distributions, audio, video, movies, certainly a cross-platform solution like a zip file might make more sense.

Both, both compression mechanism, I'm sorry. Both delivery vehicles offer compression. As we saw in the previous two examples, disk images offer a background picture. Zip files don't. Another advantage of disk images is that they offer a license agreement to users. On double clicking an image that has a license agreement tied to it, the user will first be presented with the license agreement, which they have to agree to, before the disk image will be opened and presented to them.

Disk images can be Internet enabled. We'll talk a little bit more about that in a couple slides. And lastly, disk images are resource Fork-aware, which if that means something to you that's great. If it doesn't, don't worry about it. So what we want you to take away from all of this is that disk images offer a superior user experience.

Here's an example of the license agreement sheet that comes down. This is actually from Firefox. This comes down when you double click the disk image for the first time. If you decline, it won't open the disk image. So this is a great way to you know, force your users into a license agreement and keep your legal department happy.

So how do you make a disk image? Well we've got a command line tool, usr/bin, hdiutil, it's got a great comprehensive man page. Go check it out. The three lines on the bottom of this slide take us through the creation of a disk image. The first line creates the disk image from the folder MyApp. The second line internet enables it and the third line compresses it. We're going to get to Interent enabling in just a couple more.

Advanced hdi util, using the unflattened command, will expose resources in it so when you can for example, add a license agreement. It's a little more complex and there's documentation on the ADC website on how to do that. One thing to note, too, is that if you check out VersionTracker or downloads on Apple.com/macosx, there is some great third-party GUI tools that make management of disk image distributions that much easier.

All right, so Internet-enabled disk images. What it is this? So the user experience is great. The user experience is that the user clicks and disk image download think in Safari. After the download completes, the contents of the disk image are available in the downloads folder and the user had no idea that the content was archived at all. It's a great user experience when used with packages.

And the reason for that is that if your disk image contains a single package, which Jack will talk about in the next section, packages, the installer will automatically launch the package. So the user experience in that case is that the user goes from clicking a link in Safari to immediately being in the installer, installing your software. A couple clicks, next, agree, install and close and they've got your software on their system.

The implementation details of disk images are less interesting, but we'll go through them. The disk image after being downloaded is mounted, its contents extracted into the parent directory, the disk image is unmounted and then moved to the trash and like I just said, the package is automatically opened if you have a single package in your disk image. So that's disk images. I'm going to turn it back over to Jack to talk about packages. Jack.

Thank you Luke. Okay, so packages. Probably a lot of you are here to learn about the installer, so that's what we're going to talk about now. And, but before we do that, a quick little diversion. So how many of you have come to us from the other platform? A few, okay, a few, couple of you.

Okay. So when talking about installation on Windows versus installation on the Mac, there's really one thing you've got to know, which is that basically, installation on the Mac is simpler. For better or for worse. So we'll talk about for better first. Generally speaking, you're only concerned with the installation of files.

There really is not registry to worry about and kind of along these lines, you tend to do things like create preferences files on application first launch and our APIs and core foundation and Cocoa make it really easy to do that. Whereas on Windows, for whatever reason, there's much more of a model of installers installing preferences files.

We tend not to do that on a Mac. The Mac has the concept of bundles which make it really easy for you to organize your application binary along with resources whereas in Windows, you tend to spray a bunch of files in one place and makes it a little more challenging to deal with upgrading that software after the fact because there's the potential for users to move things around, etcetera.

What's more, we have free and easy to use dev tools. We're going to show you a PackageMaker in a minute. But we think it's pretty good and it's gotten substantially better as of this Leopard release and on Windows, there are a number of things available, but they tend to be expensive and large.

We found that in the course of delivering installers on Windows for our own software, iTunes, etcetera, that sometimes we run into trouble with things like JScript and we're actually kind of moving away from using that and just writing C code to do everything we need. But on the Mac of course we have the whole suite of UNIX command line tools and scripting line which is, in fact we encourage you to use things like Perl and shell scripts in your install scripts just to avoid any binary incompatibility issues.

But it's not all good. It's simpler, because we have fewer features, notably uninstall and something that probably some of you are going to ask us about in the Q and A, but we'll get to that later and what's more, we don't have a C API for dealing with the installer.

Okay, so let's get back to packages. So, basic features of the installer are that we offer a compressed payload and we offer the ability to present some UI to the user at various points in the install process. Throughout the whole process you can have a background picture that's displayed in the main install window and we also have a welcome text which is available upon first launching the package. A read me which is useful for displaying things like release notes, etcetera.

A license agreement, obviously we've talked about that. And conclusion is available which is the final message that you see upon the quit or restart button being presented at the end of a file copying process and that's available in 10.4 or later. So, let's get to the demo machine here and have Luke talk about or show to you, a screen saver. Some, creating a basic package in PackageMaker. Take it away Luke.

All right. Thanks Jack. So PackageMaker 3.0 in Leopard. Let's take a look at it.

Okay, the first thing I need to do when I launch PackageMaker is provide my organization name. You can really put anything in here that you want, it'll accept any string. The way we do it at Apple and the way we recommend that you do it is reverse DNS naming with .pkg after your organization's name. So if I am working at acme.com, I'm going to do com.acme.pkg. the application we're distributing is my MyApp. So I'm going to put MyApp.

And this app leverages some Tiger APIs. It is binary, it is compatible with Leopard. We checked that out and so that's cool, however we know it doesn't run on Panther, so we won't allow this to run on Panther. So that's our minimum target. So those are the first two things we need to set up when creating a package. So we dismiss the sheet there and here's PackageMaker. For those of you who've used PackageMaker 2.0, earlier versions of PackageMaker, you'll notice that we've really moved to a more work flow oriented interface. So it's less like a property list editor, more like Xcode in some ways, really.

So, I've got all of my content over here and this is actually the first step, before even launching PackageMaker. You want to assemble all the content that you're going to distribute. So over here in my demo 1 folder, under my build results I have my application that I want to distribute, I have a read me file from my documentation department and I've got a license file from my legal department. So, given those three things, let's make a package.

So right over here I've got some instructions drop contents here, all right. Now we're going to install MyApps, so drag it over. Cool. Okay. So MyApp is over here and it's installing the file that we just dragged over that was on our desktop and it's going to install it on the user's system in /Applications. Now PackageMaker makes some good guesses when you drag files in.

since this has the extension .app, it assumes that we want to install it in /Applications. So it'll populate this field automatically. If you dragged into widget, it would populate with /library/widgets. I think there are a few other cases where it makes smart decisions. Otherwise it'll just present slash and you can adjust it as appropriate.

Now, I need to go over here to the components section and unclick this check box. We're not going to talk about that right now. Jack's going to explain about that in a later portion of the, of the session. But the next thing we want to do is if we go up to the top level here, package parameters, we want to edit the interface because we still have that license and read me to include in the package.

So this is kind of cool. I've got a window comes up and it looks a lot like the installer with the drawer popping out of the right side. What I can do is click on any of these bullets on the left hand side of this window and drag in content.

So I'll click on read me because I have a read me file, let me drag this in and it's just hello world, we clearly didn't spend a whole lot of time on this one.

But this supports RTF so you can incorporate graphics and fonts and really do a beautiful presentation here.

License agreement we will drag in as well. Same thing, supports RTF as well as multiple languages. So you'll notice down here we've got English. If I had license agreements in other languages, I could add them using the plus key over here. However I don't. This is an English only release. So that's that. So let me close this down.

Now the next thing I want to do is actually save this PackageMaker document. Like I said, this is kind of like Xcode and in that sense, you can actually save your working document so that you can come back later if you made a mistake or if you've got version 2.0 of your product that you need to release and make some adjustments and rebuild a package without having to go through, slug through all the steps all over again.

So I'm going to save this as MyAppPackageSpecs and it'll add a .pmdoc doc extension and we'll just put it on the desktop to make it easy. Save that, okay? Cool, it's right there in the finder. So I'm ready to go. I'm going to go ahead and build and run this package. It'll build it and we'll launch the installer. So let's see, we'll save it as MyApp on the desktop.

Okay. So welcome to My App installer. You will be guided through the steps necessary to install this software. That's just something the installer puts in if you don't have a welcome file. If you did have a welcome file, this piece would be replaced with that text. Hit continue. There's our read me. Hello world. We can print or save it if we want.

Continue on, hey, there's our license agreement in English which is the only language we specified so it's the only thing available in the pop up. And I agree, it is in fact a license agreement because it says it's a license agreement. That's cool. All right, so it says it'll take 4 MB of space on my computer and we remember that this is going to install in /Applications, so just so you know that we are not doing any slight of hand here, I'll show you our applications folder and we'll organize it by name and let's see, is MyApp in here? We've got mail and we've got photo booth. So MyApp is not in here. Okay, let's shrink this and let's do our install.

Cool. All right, let's close the installer and let's check the applications folder again. Probably way at the bottom. It's going to be MyApp. So we've just installed it using a package. And that is a basic package demo. Let me turn it back over to Jack for some more advanced features of packages. Jack.

Thank you Luke.

Okay. So what Luke showed you is obviously pretty simple. Yes, we can install simple text. But let's talk about what we can do beyond something that simple. That's pretty much accomplishable with a disk image. So let's talk about what else we can do. So, admin authorization. Obviously if you distributed a disk image that had two things to install, it would be annoying for a user to not only have to navigate to two different locations in the file system, but then an unprivileged user would say have to drag- install your font and then drag-install your application and the fact that we're able to authorize once in a package installer makes it a lot easier.

So, requirements. So the installer has the ability to enforce that certain criteria are met before you're allowed to proceed through UI and actually install files. So there are two different hooks that we provide. One applies for the system as a whole and those checks are run immediately upon double clicking the package and the other and we call that the InstallationCheck mechanism.

The other mechanism is called the VolumeCheck mechanism and it is run per volume and you can do things like enforce that a minimum version of the OS is present on the given partition or that a certain version of another piece of dependent software is already installed. So, again we're going to haul Luke back up here and he's going to show you how to make some basic requirements using PackageMaker. Demo machine please.

All right. All right. Thanks Jack. Okay, so just for kicks, let's close this down and sure we'll save our changes. Okay. Let me throw away the package that we just made and really throw it away. Okay. Let me load up my PackageMaker document from before. Okay, cool. So it's still got our app in here, it's still go all of our interface stuff, so great. You know, I had a chat with my engineering department though and they told me that this is pretty hard core text editing application and actually requires at least eight processors.

So.

We are going to check for the number of CPUs such that it needs to be at least eight. And you know what, I don't know what computer I'm working on so that might actually pass. We're going to check for sixteen.

And the failure message here, will be you need at least 16 processors to run this upgrade.

Okay. And we'll just put the same thing in the message. Okay, we'll save that. And cool, that's one requirement we can add and remove more if we need to, but that's all engineering told me, so that's all I need to worry about. Let's save this document again and build and run the package from it. Yep, we'll save it as myapp.pkg on the desktop.

Okay, oh, what was that? My app cannot be installed on this computer. You need at least 16 processors to run this upgrade. Okay, so I can't install this at all. The sheet comes down and my only option is to close the installer. There's no way that I can install this on a machine that the software won't work on, which is great. You don't want users doing that. So, let's go back and edit this package and put in a reasonable requirement.

Double click on this and we'll say that we need at least two processors and again, I don't know what kind of machine I'm running on so this might not work either. Okay, we'll save the document and we'll build and run the package. Let me delete the old package first though.

Yep. Okay. All right. So now it's letting me go through like I expected. The requirements check was run but it's invisible to the user. Great user experience if your computer passes the checks. So that's an example of requirement checks in action. Let me pass it back over to Jack.

Slides please. Thank you. Okay, so basic stuff. Let's get a little more complicated. So, this is a little screen shot from the Xcode tools installer, I'm sure you've probably seen this before and the line items that you see there are what we refer to in installer parlance as a choice and you'll see that language choice throughout the PackageMaker UI.

A choice have, choices have a couple of properties. First of all there is a hierarchy that you can establish using sub choices and choices also have an enabled or selected state. In this example here, the developer tools essentials are disabled and selected and everything else is enabled but, only the Dashcode, the reference library and examples are selected. I guess we don't want Java API Documentation installed by default, it's knocked in.

So a couple of things to note about choices is that prior to 10.4, there was a 1:1 relationship between choice and what you, between choice and package. Whereas beginning with Tiger, you can have many choices, you can have many packages associated with a choice so that you can have a simple UI, but actually install many packages depending on your packaging needs.

And these enabled and selected states are dynamic. You can actually write JavaScript to influence how these behave if, for example, you want one choice to be enabled only when another choice is selected, you can do that and they can have complicated relationships. We actually designed this to work with the Final Cut Studio installer which is really huge. It has hundreds of packages and really, really complicated UI. So we're pretty confident that you'll be able to achieve what you want to achieve.

One note is that prior to 10.4, the ability to do this is actually quite limited. It runs tools and looks at the exit value and it's kind of arcane. Thankfully PackageMaker shields you from most of that but if you need to do anything fancy, you might not be able to do it and feel free to ask us about it. We can help you out. Okay, so custom install. We're going to bring Luke back up here, go back to the demo machine and take it away Luke.

All right, thanks Jack. So Steve mentioned yesterday in the keynote that we've got about sixty seven percent of our user base running Tiger. So you've noticed probably that in a lot of the slides we've been talking about features that are available in 10.4 and later. So I'm not sure how many of you are sort of concerned with the versions of Mac OS X you want to support. But if you're looking to distribute to Tiger and later customers, you've got a pretty big market. So in a lot of cases I think it's safe to stick to those features and leverage them. So, same thing. Let's delete our old package and let's open our PackageMaker document.

Okay, cool. So one thing we didn't mention when I made the first package is that by dragging the application into the sidebar here, it actually created a choice for us. That's what this line is with the blue bubble and when we click the disclosure triangle, it shows us what is in that choice. So for example, I could have that choice install an application and a widget.

I don't want to do that so I'll delete that but, I've also got a couple other things that I want to install. I've got this widget and I've got some user documentation. So let me drag those in and PackageMaker is going to make choices for each of those items and it was real smart about the widget's thing, it figured out that it was a widget and it's going to install it into /library/widgets. User documentation, it doesn't really know what to do with. It wants to install it into slash, for the time being we'll just let it do that.

Let's go take a look at some of the specifics of the choices. So clicking on My App choice, gives us the parameters of the choice and the initial state here is that this is selected and enabled. Well, we figure that if the user install this package, they want the application for sure. So we're going to have it selected, but we're not going to have it enabled. Meaning that if the user's installed this package, they have to installed the application. There's no way around it.

The widget choice, we're going to enable but we're not going to select by default. We think maybe most users won't want the widget, maybe it's a Pro feature. So we'll leave it enabled so you can select it, but it won't be installed by default. And user documentation we want selected and enabled. We want it installed by default but if folks don't want to install it, that's cool, they can uncheck the box. So let's save this and create a package.

MyApp and we're building a package. Oh, and we got a build error. So also kind of like Xcode, PackageMaker will walk you through errors and warnings that you run into during package creation. So what did we get? We have one error, zero warnings. Distribution title must not be blank.

Okay. And I've got a magnifying glass icon over here, what does that mean? What if I click on that? It actually brings me to the point, it's to the place in the UI that I need to fix.

So, put a string in there, we'll just call it My Application and now that that's fixed, I'll save the document and we'll try to build it and run it again and see if that fixed all our problems.

And it did. And I need two processors to run this upgrade. I don't know what that is. That's hm, hm. Well, let's go back to the package and I'll pull that requirement off for the meantime. We'll save it and delete this and build and run and cross our fingers. Okay, great.

So if I continue through, we've got all our stuff from before, agreed? I'm going to customize this and sure enough we've got the changes that we made in PackageMaker. My App must be installed because, well, that's hard to read, it's got a disabled check box that is checked.

My widget won't be installed but, I can install it if I want to so sure why not and user documentation, no I'm a pro. I don't need that. So we'll go ahead and perform the install and it's going to go by really quickly, but it will say My App installing and My Widget installing. So see if you can catch it. My App, My Widget.

Okay. Close and we've installed My App and My Widget and so that's an example of using choices in the installer. Let me hand the presentation back over to Jack Jack.

Thank you Luke. Okay, well we have either something wrong with PackageMaker or something wrong with the demo machine. But anyhow, okay.

So some more advanced needs you may have. Relocatable choices, again going back to the Final Cut Studio example, it's huge and some of the content actually fills up an entire DVD and that can fill up your hard drive pretty fast and so what we have is the notion of being able to relocate some of that content and we're doing that here via a choice, which is a relocatable choice and that will actually reroute all of the contents associated with the choices that you see below to a different hard drive probably.

Multidisc installation. So again, Final Cut Studio, it's six DVDs, DVD nines, quite huge. So we're pretty sure that it'll work for ever, for whatever you guys have to do. Plug-ins. So, if you were to launch the Final Cut Studio installer pretty early on you'd be presented with a UI asking you for a serial number.

This is great. It's a good way for users, it's a good thing for users psychologically because they can kind of take care of all their set up needs really early on and be done with it. But there are a number of caveats when we talk about plug-ins and extending the installer's UI which is that first of all, they're not guaranteed to run. So for the obvious example here is if you use the command line installer.

Well, there's no serial number entry of the command line installer. What's more, you shouldn't be using the, something like a licensed plug-in as a real gate keeper for any kind of copy protection. Because well the users can either go to the command line or they can go get a tool from VersionTracker and just rip the contents out of it and put it wherever they like.

So the thing you should remember is that it's a nice convenience for the user to have this kind of a thing implemented as a plug-in, but you should also do the same thing in your app and handle it on app first launch. Finally, there's no integration between PackageMaker and plug-in. So, by all means, use PackageMaker, but at the end of that process, you're going to have to insert the plug-in bits into the package after the fact.

Okay, so what happens after you click install? Upgrades. Upgrades are the notion of the installer examining the target disk and looking at what it has to install and it checks for any older versions of that package and it does that by the identifier of the package. That stuff that Luke was typing into the PackageMaker UI up there.

And what it does is it sees if there are any files that are no longer present in its payload, that are on the disk. So it will go and do things like for example, if you no longer support a certain localization, it'll happily remove all of those localization files as part of the upgrade process.

A thing to note, this is determined by the bundle identifier or the package identifier in the case of a flat package, of the package and so what you don't want to do is go reusing that same identifier, because if you're distributing two applications and they have the same identifier, it'll happily go and remove all the files associated with you other application and that's bad.

So, version comparison. If any of the files that you are installing happen to already be on the disk, independent of whether it was packaged in some other package beforehand, we will make sure that there isn't already a newer version of that bundle on the disk and we don't stomp out any newer versions.

It is overridable in the PackageMaker UI. If you have individual files that have their own kind of internal versioning scheme, it's possible to hand the installer a piece of code to run to do a version comparison for you. We have some documentation on that. We're not going to talk too much about that here.

And of course, pre and post installation scripts can be run beforehand, after the fact or in both cases, for any of your packages and the installer will just go and run a binary but again, we suggest that you use something like Perl or shell that won't have any binary incompatibility issues.

Okay, locater. So you may recall earlier when Luke was doing his first demo, that he went and unchecked something and what that something was, was the installer's locater feature and he did that because in the course of his demo, had he done that, the installer would have found the old, the same version of that application in it's build results folder and upgraded it there. But this is a useful feature obviously. If you install any of the OS updates, we do that. So if you've gone and organized your applications folder in some specific way, we go and find those previous versions and upgrade them in place.

So, cool thing about locater in Leopard is that it's been enhanced quite a bit and first off, it's easier to use. You can actually influence how a locater works through JavaScript. You can use locater results as search, excuse me, as requirement and requirement criteria for either the installation as a whole or for individual choices which is really cool so, for example, you can say that the user can't proceed with installation unless locater finds some old version of your app. Really handy. And, along this lines you can also pass the results of what locater found to a pre or post install script. Very, very cool.

So that's segues to Leopard new features. Flat file packages. That's probably the biggest feature here and as Luke mentioned earlier, in Leopard, a flat file is an archive container. It's the thing you download, it's the thing you can double click and run. And because we have this, it's really easy to get cryptographic signing. So that's one cool thing. We have better compression using bz2 and we now have for flat packages a utility in Leopard called pkgutil and that allows you to examine properties of a package that's either that ever has been installed or that has yet to be installed.

A few other things. Home directory installation and binary patch packages. We actually had binary patch packages a little while ago, but they were really hard to make and so finally we have a good UI around it in the new PackageMaker. Okay, installer best practices. Packaging. So, you should package your software in a modular way.

What I mean by this is that you don't, you probably don't want to group together your documentation and your application in the same package. You probably want to be able to update your documentation independently and not have to touch your application that's already GM'd in some other package.

And this works really well when you talk about doing upgrades. And again, along those lines, use a unique identifier for those packages and you don't have to worry about it too much if you use PackageMaker because it guides you down the right path and puts sensible identifiers for packages and creates individual packages as you drag things into it. But it's just something to be aware of.

Okay, so if you just remember a few things, really just use packages. You can use packages and use PackageMaker to create them, but if you have a reasonably competent user base and you're just distributing one thing, a disk image based drag-install is a pretty good way to go, too.

So, that brings us about to the end here, but further information. We have an installer release notes document and that's probably the single most concise place to really understand a lot of the nitty gritty details about the installer document format and how the installer behaves. There's also a brand new PackageMaker user guide, which goes over the PackageMaker 3.0 which we've been showing you here.

We have a lab tomorrow from noon to 3:00 in Lab C and finally, last year's presentations are actually quite useful. They go into a lot more detail. This is really a 50,000 foot oPverview of what your options are here. But there's a lot more detail in those presentations and really all that still is applicable. So.