Packaging a legit .pkg as a .dmg

[llitz123]

I don't know much and I'm still muddling through Casper.
I'm still waiting to implement a user interactive software update policy for mobile users forcing them to run updates which reboot their machines...
In the meantime, I have the JavaForMacOSX10.6.Update16.dmg to manually roll out to our 10.6.8 machines with Casper. My issue is that a good number of the laptops I need to push to are remote with various network connections and uptime.
From what little I know a .dmg is best in these conditions as it can be resumed where a .pkg cannot.
Is there any way to repackage the .pkg into a .dmg for better update stability?
If not, and I push the update via .pkg and the update is interrupted because of network or user instability, will clients eventually get updated or will interrupted updates cause further issues I don't want to deal with?
Thanks for any assistance.

[mm2270 · Accepted solution]

Actually if you're using http(s) for your distribution points, you get resumable downloads, no matter the format of the file, I'm almost sure. You don't get resumable downloads with AFP/SMB shares though so if someone closes their lid in the middle of a file being pulled down, its hosed.

I would not try repackaging a .pkg into a .dmg personally. The only real way to do that would be to do a Composer snapshot and that adds extra headaches to worry about, like missing the postinstall/postflight scripts, extra junk getting picked up during the snapshot, etc.

[RobertHammen]

While you could push out a .dmg, then write a script to mount it and run the package, I would:

a) cache the .pkg locally on the machine, and then create a separate policy to install the update once it was cached
b) ensuring I was using an http distribution point (since http downloads are resumable).

[JPDyson]

You could do it in one policy; have the .dmg put the file in a certain location on the Mac, and then call an 'after' script (or a manual command under 'Advanced') to install the package. You could do it a few ways, but I have recently used `jamf install` with success.

$ jamf help install

Usage:   jamf install -package <filename> -path <path to file> -target <volume>
         [-fut] [-feu] [-showProgress] 

     -package        The filename of the package that will be installed.
     -path           The path to the package. This does not include the name of the package.
     -target         The drive that the package will be installed to.
     -fut            The Fill User Templates option takes any user data 
                 and populates the files to the user templates so any new 
                 user created on the system will have these files.
     -feu            Fill Existing Users option takes any user data and 
                 populates the files to every user on the computer that has a 
                 home directory.
     -showProgress       Displays the progress of the HTTP download and the progress of the installation process.

[mm2270]

Or you can use the built in installer command line-

/usr/sbin/installer -pkg /path/to/downloaded/package.pkg -target /

Honestly though, it would probably be best to enable http on your distribution point if that's a possibility. Then you won't need to worry about workarounds for clients that may sleep during policy execution.

As per RobertHammen's suggestion, you may also want to look at using caching in one policy and installing via another, especially for larger installations. Just create a Smart Group using the Receipts section to gather any machines with the cached package for the installation policy.

[llitz123]

Thanks for all the responses. I'll verify it's using http and at some later date I may revisit and try other, more advanced suggestions.