Skip to main content

With Apple's new way of distributing the Pro apps, it seems I have to repackage each update for redistribution. Not so bad it seems at first, but I'm running into a bit of a situation.



Initially deployed Final Cut Pro X 10.0.2
Now we want to deploy v10.0.4
Apple tells me to just 'update' one of licenses and capture it to distribute again.



Sounds simple, but my conundrum is how do I remove the old version and replace it with the new one. I did not 'index' the .DMG I have in Casper Admin because it is over 2GB in size!



I had an idea to put in a 'rm' command into 'Run Command' but it seems that it gets run after installations take place (though I could be wrong)



Anyone have any suggestions or care to share how they have tackled this issue?

It seems like you have two options:



1.) Index the installer and then create a policy that will uninstall the previous version, and then install the new one.



2.) Build the installer as a .pkg instead of a .dmg in Composer, and add a preflight or preinstall script that deletes the previous files and directories before installing the new package.



~Ted

We use a preflight scrip that runs BEFORE on the policy:



rm -Rf /Applications/Final Cut Pro X.app


Haven't had to remove anything outside the app bundle.



[Sorry Ted, after I hit send I noticed you posted the same thing.]



Don

I'd create a standalone script to run in the policy with a priority of "before" - have the script kill Final Cut if the application is open, then rm the app...

I include the preflight/preinstall scripts in the majority of my .pkg installers, because of the workflow I use to deploy applications using Casper. Most of my packages are sent down to the computers, cached any time they are on local Ethernet, and then are only installed at restart or login. By building the uninstaller into the .pkg, I can keep my install policies pretty simple. There are occasions where I have Casper install the apps, rather than cache them, and having Casper execute the scripts works great as well.



Different strokes for different folks! :-)



~Ted

Thanks all!



I ended up putting the 'rm' command into a script to run as a Before, as I will be installing it after hours so I can control the access and usage so there will be no slowdown for users.



David

Reply


Terms & ConditionsCookie settings