Generally doing a munkiimport on a .app or .pkg to get it into a Munki repository will tend to just work. Munki will automatically create the appropriate .plist file and know whether an app is installed or not based on the receipts or based on an installs array (more details at How Munki Decides What Needs To Be Installed).

Occasionally, you come across a badly-constructed .app or .pkg that Munki doesn’t know what to do with. A great example of this is Oracle’s SQLDeveloper.app, which comes in different versions, but the .app itself has no indication of what version it is. By default, all (recent, anyway, as of this writing) versions of SQL Developer show as version 1.1. So version 4.1.1.19 is 1.1 and version 4.1.2.20.64 is also 1.1. The only way to know the actual version you’re using is knowing what it was when you downloaded it. The .app itself doesn’t contain the version number in any obvious place (in this particular case, it happens to live in SQLDeveloper.app/Contents/Resources/sqldeveloper/bin/version.properties, but how would Munki know to even look there?).

Having every version of the app identify as one version poses a couple of problems. Still with SQL Developer as an example, if you import 4.1.1.19 as 1.1, that’ll work fine, until you want to import 4.1.2.20.64. If you import 4.1.2.20.64 as 1.1 also, Munki won’t know to upgrade clients to the new version. And if you import 4.1.2.20.64 as 4.1.2.20.64, Munki will keep thinking it has to upgrade (the install/upgrade process will keep looping), because it won’t see 4.1.2.20.64 as 4.1.2.20.64—it will see it as 1.1!

So, apart from filing a bug report with the developers and hoping they fix it, there are a couple of workarounds you can use.

Workaround #1: Find a unique part of the .app and hash that

Instead of running the normal

which will get you that the version is 1.1, you can do

In SQL Developer, that’s the unique thing that changes (the shell script and binary do not), but in a lot of other applications you would want to find the binary and hash that (e.g., /Applications/NAMEOFAPP/Contents/MacOS/NAMEOFBINARY). When you run the makepkginfo -f command on the binary file or shell script, it’ll create an installs array that includes an md5checksum key, which should, presumably, be different between different versions of the app.

Workaround #2: Manually change the version number

Another approach is just to do what the developers should have done in the first place—go into /Applications/SQLDeveloper.app/Contents/Info.plist, and edit the version there before importing the .app into Munki. So, as an example, for SQL Developer, I changed

to

and then did a munkiimport, and everything worked fine on the installs/upgrades front.

Acknowledgements

Thanks to Greg Neagle for not just developing Munki but also for support on this particular issue via the Munki Discuss mailing list.