Skip to main content

Has anyone been successful creating packages for Adobe Shockwave without performing a snapshot? If possible, I'd like to not lose the installer logic, so I'd prefer not to have to snapshot the install.



I don't know if it's because they've baked things into the installer or if it's the same SMB problems, but it fails when I just drop the PKG into Casper Admin.



I've tried converting it to source in Composer, but that just throws installer errors (this makes me think they baked things into the PKG rather than a SMB problem). I also tried using The Unarchiver on the PKG and found another PKG inside, but that just causes OS X to report that it is broken and offers to throw it in the trash.



I haven't tried any other packaging applications, but I'm certainly willing if that's what it takes.

Nothing makes me cringe more than "snapshots"...to your point, there's a reason developers build logic into their PKG/MPKG installers. Anyone who thinks a snapshot is a smart way to deploy software that shipped with installers containing logic, well...I'll withold my snide remarks. :):):)



If you open the full Shockwave PKG in Pacifist, you'll find there is only one preflight script containing simply:



#! /bin/bash

sudo rm -rf /Library/Application Support/Adobe/Shockwave 11


Could it be that Adobe's installer development team are maturing? :b



Pacifist is one of the most valuable tools for examining PKG/MPKG installers. Here are screenshots of the Shockwave Flash installer. Seems at first glance like a nicely designed package. The litmus test would be to push to a freshly imaged Mac (virtual machine in ESXi or physical?) and circle back to see if any permissions got whacked (most mature tools default to NOT altering existing directory ownership/permissions), etc.



Package Contents



external image link



Resources



external image link



These are the kind of clean PKG/MPKG installers we deploy with absolutely no modification. Including (but not limited to) not renaming the original PKG/MPKG. Using your favorite tool, drop the PKG/MPKG (or even the DMG) into /tmp and trigger it with the standard commands.



This ensures Casper has a receipt that follows your naming convention, by naming YOUR package using your company's package naming convention, for example vendor-application-version which would show up as "Installed by Casper":



Adobe-FlashPlayer-12.0.2r122



...while preserving all the criteria set by Adobe (package name, version info, bundle info, etc.), which shows up under "Installed by Installer.app".



All third party PKG/MPKG's should be properly vetted, and if it passes, simply wrap it and deploy. There may be a command you might need to run (Flash Player), but the same packaging/distribution methodology applies, including the necessary commands in a postflight script. Flash Player, Adobe Reader, etc...long list of installers that you can deploy using this method, and trust that later on you'll be in the best position (rather than winging it with a snapshot and hoping for the best).



Don

Thank you so much Don. That was a very informative and useful post. I can't believe I didn't think to just wrap the PKG.



I was able to install it that way locally by clicking on the wrapped package and it installed using the native installer, then deleted that from its temporary location. Though I'm still wondering why it was crapping out on me when trying it without wrapping... :-/



I'll have to properly test it on Monday when I'm in the office and not on "me time."



I've downloaded and I'm getting ready to install Pacifist. Hopefully this will help with the stupid HP DesignJet driver.app file that doesn't seem to have a way to trigger silently. I think that and the Epson scanner are the only 2 packages that I haven't found a way to avoid doing a snapshot.



Wish me luck, heh.

Did you start with the full installer? If not you'll need to apply for distribution permission, then Adobe sends you the link to the full installer. The full installer is what I used for the above example.



external image link

Yes, I already have distribution rights and I used the full installer. Funny thing is that for Shockwave, it's the same file as the one from the public download.

To clarify, I wasn't saying that wrapping it didn't work. I was saying that I'm still stumped as to why it was necessary.

Does anybody have any advice for packaging the Shockwave Uninstaller?

@ianmb Don't know anything about the uninstaller, but you could index the installer and have a policy to uninstall?

I mounted Adobe Shockwave Player 12.1.5r155.dmg then viewed the contents of the Shockwave Uninstaller app, which contains an AppleScript:



external image link



Based on that I think the easiest thing to do would be to upload and run a script with the same language, or use the Remote Commands function, to remove the plug-in. I'd also put up a completion message reminding the user to close and re-open Safari and/or Firefox.

In my 5/11/13 post I didn't mention that the pre/post install scripts had syntax errors.



But I did report to Adobe...fast forward a couple years, those syntax errors still exist.



Adobe's Shockwave team are quite an example of cost savings over quality...




What the.....Does that even work?

We created pre/post install scripts to run before/after the policy to do what the embedded scripts were supposed to do. Kind of like flipping the burger for McDonalds.

Hahahahahahahaha.....typical Adobe....



# pkgutil --pkgs | grep shockwave

adobe.adobeShockwavePlayer.shockwave12.pkg
Terms & ConditionsCookie settings