Old topic, new thread... .PKG vs .DMG

I have four different approaches, depending on the specific package:

1. Vendor Provided. If the vendor provides a package and it installs fine through Casper, I rename it to fit with my standard naming scheme but otherwise leave it alone and use it as is.
2. Special Packages. Sometimes a vendor will create their own installer that you have to use, to properly license the product, which doesn't allow you to (easily) use a standard method and that requires a custom workflow to deal with. Microsoft Office, Adobe and Parallels fit in here.
3. If I have to make a custom package using composer, I prefer to use a .dmg as they index better and often will install faster. However, .dmg's don't allow you to run pre/post-install scripts so...
4. If an installer requires pre/post installation scripts be run, I resort to building a custom .pkg

Our standard is .pkg with the following two exceptions:

1. If for whatever reason the installer continually fails on a .pkg (edit: I should say erroneously fails), I repackage it into a dmg so it gets "forced" on to the system. The Wacom tablet driver installers are a good example of this.
2. Casper Suite. We often have to run casper admin from a users workstation if they have a special printer setup so we can capture the ppd, and I don't want to install CA if I don't have to. This way I can mount the casper suite dmg and run the needed apps from a server share. We ID casper admin stations by the presence of a CA app so you can understand why I wouldn't want this app installed all willy nilly.

We leverage pre- and post-flight scripts heavily at my company, so dmg just doesn't cut it. We also make it a practice to package an uninstaller with every installer, so indexing for the purpose of uninstalling is not necessary, but it is useful in other scenarios.

I also find that Caspers logging ability, as far as software installation goes, is woefully inadequate as CR and CI logs will simply tell you if the install passed or failed (this goes for pkg and dmg packages - usually with a pkg though, it will give you SOME sort of indicator as to what/where it failed, but not always). The difference here is that with pkgs, I have the install.log file that I can look through for failures, script results, etc. No equivalent on the dmg side of things. Error reporting/capturing/handling are of paramount importance to me as a Mac admin.

@easyedc][/url, curious - why does packaging as a dmg have anything to do with your team being windows based?

I tend to prefer .pkg so that I can also use it in my DeployStudio workflows. If I need FEU/FUT then that's the only reason I use .dmg.

@acdesigntech][/url the windows based comment is more designed to be that they don't understand much about OS X administration and we get a lot of errors (permissions, ownership, legacy/dead files, other things). If I were 100% responsible for everything Mac related, it would probably be a different approach, however, we're a large organization with specific roles for various aspects of workstation management.

The approach that they use is that they will normally just install the software to make sure it doesn't crash their machine, at which point they run the snapshot function and don't clean up after themselves or look at all files that get installed.

I am a huge fan of portability and easy modification. For that reason, I always go with packages, and I handle any additional functionality with postflight scripts if I need to populate user profiles. Packages work in literally any scenario, where DMGs don't.

The only time I use DMGs is if I am mounting and opening one to present files to the user, if they need to take action.

You really have to cook up both and see which tastes better in your kitchen.

Composer dmgs are convenient for attaching user prefs, but otherwise very limiting in use.
Unmodified vendor packages whenever possible to retain the vendor provided voodoo.
Adding Postflight scripts in custom packages is a huge convenience at times.
And the big one for me is that packages can be used with ease outside of the Casper sphere.