Converting previous DMGs to PKGs using Composer

Packages: http://s.sudre.free.fr/Software/Packages/about.html
Or pkgbuild / productbuild and pkgutil. (Note: the last one is not for packaging but can certainly provide useful info about packages)

or munkipkg: https://github.com/munki/munki-pkg (despite its name, it does not require and is not exclusive to Munki only)

I've had luck taking some of my DMGs and converting them to source within Composer and clicking "Make PKG" and appending my installer cert. That being said, before doing that, I always would recommend re-evaluating your package to see if you need to build a new one. Files might be out of date, you may not want things how you did them a year or two ago. You also will have to re-evaluate if you were using the FEU or FUT features. I tend to use PKGs most of the time these days unless I am deploying a simple file or two and wanting that in the User accounts or user template.

As for using Composer itself, things seem to install fine, but again, I mainly use PKGs to start with these days and only use DMG for 1 or 2 files that need deployed to /Users. I build a separate support DMG for that on top of the main PKG and push both with my policies.

I have written a book on the topic:

Packaging for Apple Administrators

It explores how to inspect packages with pkgutil, Pacifist and Suspicious Package, how to build them from scratch with pkgbuild and productbuild but also third party tools such as Whitebox Packages, munkipkg and Composer.

That said, you could convert a dmg created with composer to a pkg with the following sequence of commands:

1) mount the dmg:

$ hdiutil attach /path/to/Sample.dmg

this will output a bunch of info, the very last bit is the mount point of the dmg /Volumes/Sample (the name will depend on the dmg)

2) build a pkg with the contents of the mounted dmg as a payload:

$ pkgbuild --root /Volumes/Sample --version 1.0 --identifier com.example.sample --install-location / Sample-1.0.pkg

This will create Sample-1.0.pkg in your current working directory. (I like to include the version in the pkg file name, but that is entirely optional.)

3) cleanup: unmount the dmg

$ hdiutil detach /Volumes/Sample

Obviously, the pkg will not be able to 'Fill User Template' or 'Fill Every User' but this should work.

Overall, revisiting the package building process from the beginning and leveraging tools like autopkg might be a better approach, but sometimes you just have to convert.

Check the man page of pkgbuild and/or my book for more detail.

To be honest unless you have some underlying need to repackage I wouldn't go as far as trying to repack them all. The existing DMGs are still working, it's new ones that are problematic, you will find natural processes will remove most of them from use over the course of a year or so and once there are a much smaller number of in use ones then repackage the ones that look like they may be around semi permanently.
The one thing I would say though is it is worth going over really old DMGs as a matter of course, if your JAMF experience is anything like mine you will be a bit horrified at some of the things you left in earlier installers created using the snapshot method.

Thank you for the great replies and awesome ideas, I sincerely appreciate it.

@Look I have to ask. For NEW DMGs does Composer only package them up as APFS volumes only when packaging on a High Sierra? I am assuming so, but with not running High Sierra yet, I really don't know. We are moving to High Sierra on some Macs next month so I better be ready.

When I package using the snapshot method, I try really hard to clean out the cruft that exists. But as you mentioned, it is good to revisit some of the older DMGs just be sure you are installing clean stuff.

@mconners That is certainly my experience and understanding. Basically once your packaging machine moves to High Sierra your effectively limited to creating PKGs unless everything in your environment is on High Sierra.
To be honest though I really can't see any disadvantage to using PKG over DMG anyway, as far as I can tell the only functionality you lose is the almost never used index and uninstall function (I think I have used it once in four years).
I have also found that the move to PKG has generally resulted in more consistent delivery as well as DMG sometimes does weird stuff like leave mounted volumes on user desktops and what not and I frequently find myself having to add some scripting to the install process which PKG supports directly as opposed to having a seperate script in the policy with the DMG.