Avid upgrade with uninstall and reinstall

[Kenny Johnson]

I'm trying to use munki to automate an upgrade of a few Avid programs

- Media Composer
- Media Indexer
- Interplay Access
- ISIS Client Manager

The current version of MC is 8.2.4 and we are trying to go to 8.4.2

I have added all of the installers for the old software to munki, set auto remove to true, and munki seems to uninstall software just fine. However, when I then add all the installers for the new versions of the applications to the manifest to be installed after the uninstalls, it no longer wants to uninstall Media Indexer, Interplay Access, or ISIS Client manager. I've gone through and installed the old and new apps, and retrieved the installs array information for each application and added it to the pkg info files in hopes that would be enough to differentiate the old and new applications. I get the error for two of them that it cannot find unique packages to remove for Media Indexer and Interplay Access, and I get no error from ISIS Client Manager, just that it will install the new version, and nothing about uninstalling the old. If I turn the receipts inactive on the new applications, it comes right back and is ready to uninstall all of them again. All of the Avid applications have their own apps that are typically used to uninstall. How can I get munki to see the old and new applications as different items, and uninstall the old before installing the new? It seems to clearly be an issue with matching receipts, is there a way to fix this or will I have to script the addition of an included manifest after the uninstall? If so, what might that look like? simply a vi command on the manifest?

[Gregory Neagle]

Is it actually necessary to remove the old versions before installing the new? Properly written and behaved Apple packages will do the right thing when installing new versions of existing pkgs.

Without a lot more info, all I can give you as far as advice is to look at adding installs arrays for the software you wish to install.

I’d also _not_ use autoremove if the new software and the old software share receipts. Munki will see receipts that match the software to be automatically removed and will attempt to remove it.

-Greg

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
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.
To post to this group, send email to munk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kenny Johnson]

The suggested method from Avid for the upgrade is to do a full uninstall and a reinstall with the new applications. I have already added the install arrays to both the old and new packages. If I shouldn't use the auto remove functionality, would you suggest managed_uninstall, and if you don't mind, could you explain how those function differently beyond the fact that auto remove is based on it's presence in the manifest, while managed uninstall is actually the fact that it is in the manifest vs missing from it?

Thanks so much!

[Gregory Neagle]

On Dec 2, 2015, at 6:28 AM, Kenny Johnson <kennyj...@me.com> wrote:

The suggested method from Avid for the upgrade is to do a full uninstall and a reinstall with the new applications. I have already added the install arrays to both the old and new packages. If I shouldn't use the auto remove functionality, would you suggest managed_uninstall, and if you don't mind, could you explain how those function differently beyond the fact that auto remove is based on it's presence in the manifest, while managed uninstall is actually the fact that it is in the manifest vs missing from it?

Again, I don’t have the level of detail available to me to answer in the specific context of the Avid software.

The difference between autoremove and explicitly adding an item to managed_uninstalls is that you can _remove_ items from managed_uninstalls (and therefore have Munki leave something alone!)

Scenario:

AvidNew is installed.

AvidOld is set for autoremove

Munki runs, and checks to see if AvidOld is installed, using methodology similar to this: https://github.com/munki/munki/wiki/How-Munki-Decides-What-Needs-To-Be-Installed. If the presence of Avid-new causes these checks to succeed, Munki thinks it needs to remove AvidOld. IOW, it may not have enough information to distinguish between AvidOld and AvidNew.

If you cannot resolve that situation, having AvidOld set to autoremove would continually do the wrong thing, as it would also try to remove AvidNew.

Let’s look at this a different way.

Let’s say you imported Firefox-42.0 into your Munki repo and set it to autoremove.

Machines with ANY version of Firefox (even Firefox-43.0) will have Firefox removed, as removal is not tied to a version. Munki sees Firefox is installed and determines it should remove it. It sees an application bundle at /Applications/Firefox.app, and that tells it: yes — some version of Firefox is installed, so we need to remove it.

So much of this boils down to the pkginfo for all of the items in play, and whether or not Munki will see AvidNew as simply a different version of AvidOld.

This problem generally does not hit things like Office2011 vs Office2016 or Photoshop CS6 vs Photoshop CC2015, because these truly are different pieces of software that can be installed at the same time. They have different receipts and different application names or install to different subdirectories under /Applications.

-Greg

[Kenny Johnson]

Thanks so much for the clarification! I can definitely see how auto_remove is a bit of a dangerous game to play. I will continue to mess around with this. I suspect what my solution may end up being is a preinstall script to run all of the uninstaller apps one by one, which I'm working with Avid to try and establish a way of doing. I was hoping munki could handle all of it on it's own without any intervention of scripts, but at least munki is suited to handle and run scripts nicely, especially with the functionality of running as a preinstall script.

Thanks again!

[Matt Bryant]

For what it's worth, we have been using Munki to install this list of programs successfully for several years. Despite what Avid recommends, we have always simply released new versions of Avid software on top of the existing installs, and have yet to run into trouble. Another option is to use something like DeployStudio to nuke systems and then let munki bring everything back to the newest version. No messing around with un-installers. Depends on your environment.

It's Avid though, so I'm expecting trouble at some point. Test, test,  test.

If you do come up with proper uninstall scripts (or scripts to automate the licensing / activation) for these programs, please let us know.

-Matt

[Gregory Neagle]

On Dec 2, 2015, at 1:02 PM, Matt Bryant <ma...@nescom.edu> wrote:

For what it's worth, we have been using Munki to install this list of programs successfully for several years. Despite what Avid recommends, we have always simply released new versions of Avid software on top of the existing installs, and have yet to run into trouble. Another option is to use something like DeployStudio to nuke systems and then let munki bring everything back to the newest version. No messing around with un-installers. Depends on your environment.

It's Avid though, so I'm expecting trouble at some point. Test, test,  test.

If you do come up with proper uninstall scripts (or scripts to automate the licensing / activation) for these programs, please let us know.

Since Avid is recommending uninstall of the previous version before installing the new version, it seems to me that it’s on Avid to provide working uninstall scripts/methods.

Without that, I think I would have to agree with the idea of just wiping the machine and building it again from scratch with the new software.