Two Versions of Same Application

[Ricky Chilcott]

I'm trying to install two versions of the same application, Unity.  I've done this before with drag-and-drop installers, but not with a package.  What we do (which is perhaps incorrect), is install it in it's default location (is /Applications/Unity/Unity.app) and then rename /Applications/Unity to /Applications/Unity-version.  Of course, this is done in a script and is reflected in the pkginfo files (see Catalog for Unity Installers below).  On some machines, we have Version 3.5 installed, but not version 3.4, whereas others have both.  I think the machines that had both are a symptom of me adding Unity 3.4 first and then adding Unity 3.5 to the catalog about an hour later.

So, what am I doing wrong?

https://gist.github.com/1664257 -- Managed Software Update Log

https://gist.github.com/1664260 -- Catalog for Unity Installers

What is peculiar is in the MSU log, says that Unity 3.4 is looking at the 3.5 install location.  Seems like maybe it's using spotlight and not the absolute path to do the comparison?

Ricky Chilcott

[Anurag Mohanty]

I think munki is checking receipts, try removing them from the pkginfo.

-- Anurag

[Greg Neagle]

You aren't doing anything wrong -- this is expected behavior.

Munki allows users to have a newer/later version of software without penalty. It does use a Spotlight (and LaunchServices) search to find all installed applications.

When you ask it to install Unity 3.4, it sees a later version is already installed and that satisfies its check, so it has nothing to do.

To work around this, instead of using the applications themselves for the installs array, you could use the directory or the execuables:

makepkginfo -f /Applications/Unity-3.4.2

makepkginfo -f /Applications/Unity-3.5.0

This way Munki will only check for the existence of the appropriate directory and not search for applications.

-Greg

[Ricky Chilcott]

Ok… so just so it's clear.  My installs key should now look like:

<key>installs</key>
		<array>
			<dict>
				<key>CFBundleIdentifier</key>
				<string>com.unity3d.UnityEditor3.x</string>
				<key>CFBundleName</key>
				<string>Unity</string>
				<key>CFBundleShortVersionString</key>
				<string>3.4.2f3</string>
				<key>path</key>
				<string>/Applications/Unity-3.4.2/Unity.app</string>
				<key>type</key>
				<string>application</string>
			</dict>
			<dict>
				<key>path</key>
				<string>/Applications/Unity-3.4.2/Unity.app</string>
				<key>type</key>
				<string>file</string>
			</dict>
		</array>

[Nate]

You should only need the first dict in that entry.  You should be able to leave out the file dict like so:

On Mon, Jan 23, 2012 at 1:43 PM, Ricky Chilcott <ri...@rickychilcott.com> wrote:

Ok… so just so it's clear.  My installs key should now look like:

<key>installs</key>
		<array>
			<dict>
				<key>CFBundleIdentifier</key>
				<string>com.unity3d.UnityEditor3.x</string>
				<key>CFBundleName</key>
				<string>Unity</string>
				<key>CFBundleShortVersionString</key>
				<string>3.4.2f3</string>
				<key>path</key>
				<string>/Applications/Unity-3.4.2/Unity.app</string>
				<key>type</key>
				<string>application</string>
			</dict>

		</array>

[Greg Neagle]

No.

You want to _remove_ the application dict, which triggers the Spotlight/LaunchServices search for installed applications, leaving _just_ the file dict.

An alternate approach, which I just remembered, is to manually edit the application dict and turn it into a dict of type "bundle":

<key>installs</key>
<array>
<dict>
<key>CFBundleIdentifier</key>
<string>com.unity3d.UnityEditor3.x</string>
<key>CFBundleName</key>
<string>Unity</string>
<key>CFBundleShortVersionString</key>
<string>3.4.2f3</string>
<key>path</key>
<string>/Applications/Unity-3.4.2/Unity.app</string>
<key>type</key>

<string>bundle</string>
</dict>
</array>

Again, this prevents the search for installed applications and forces Munki to only consider the exact path given.

-Greg

[Ricky Chilcott]

Ahh… I guess I was confusing myself.  The whole time I've been assuming that the dict WAS a bundle, but that not what I had done.  I think that should fix it for me.  Thanks for pointing out my confusion!

Ricky

[Erik]

I didn't want to create a new thread for this, but I have a similar question.

Over the holiday break, a few Apple programs were updated but they now require 10.9. For the iLife/iWork applications, I created a manifest with conditional values as I never used the AppStore apps and used a DVD. It was easy.

With Final Cut Pro X, etc I did originally have App Store Apps. We have not yet moved all of our machines to Mavericks and I know if I import them into my munki repo, I'm going to have a ton of errors in MWA for machines not being on 10.9.

Without creating a new item and a conditional manifest, what would be the best way to import these?

[Gregory Neagle]

Not sure what your overall goal is.

But "normally" you'd mark the updates as requiring "10.9" and let Munki figure things out.

Leave the older versions in the repo and Munki will install the older versions on machines running < 10.9, and the "latest" on 10.9 machines.

-Greg

--
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Erik]

Are you saying use a <requires> key pointing to 10.9? If so, that's kind of brilliant.

If not, the pkginfo already has min_os as 10.9, but doing this alone puts errors in MWA as the package cannot be installed.

[Gregory Neagle]

Again, I don't have enough info about what you are trying to do.

If you are trying to install Foo on all your machines, and Foo 1.0 works on 10.6-10.8, but Foo 2.0 requires 10.9, then marking Foo-2.0 with "minimum_os_version" = "10.9" would result in the desired behavior, and no errors in MWA.

If, instead, you are trying to install Foo-2.0 on Mavericks machines and no version of Foo on non-Mavericks machines, you'll have to use conditional_items in manifests.

-Greg

On Jan 6, 2014, at 9:08 AM, Erik <eriknico...@gmail.com> wrote:

Are you saying use a <requires> key pointing to 10.9? If so, that's kind of brilliant.

No, that would either cause Munki to try to install 10.9 or just throw other errors.