Uninstall Adobe CC package existing of several applications fails

[Peter Bos]

I created a package installer with Adobe CCP where InDesign CC and Photoshop CC are added to.

Munkiimport worked fine and installing the applications to a client also works fine.

Uninstalling the package however doesn't work well. Only InDesign is uninstalled and Photoshop isn't.

Other tests had the same result.

Does anyone had the same problem and solved this?

regards,

Peter

[Lee Ramsay]

I apologise if this isn't of the upmost assistance, but I've never found Adobe uninstalls to be clean/final. Without having access to CCP to confirm however, you could write a post_uninstall script to clean up what's missed, if it's consistently leaving the same files behind.

I normally uninstall via reimage, with the Adobe suite.

--
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.

[Gregory Neagle]

On Sep 6, 2013, at 1:17 PM, Peter Bos <p_...@mac.com> wrote:

> I created a package installer with Adobe CCP where InDesign CC and Photoshop CC are added to.
> Munkiimport worked fine and installing the applications to a client also works fine.
> Uninstalling the package however doesn't work well. Only InDesign is uninstalled and Photoshop isn't.
>
> Other tests had the same result.

Do you see different behavior when using the uninstall package generated by CCP?

-Greg

[Kris Lou]

I've had the similar issues, but haven't gotten around to dealing with it since I pulled CC and pushed out CS6 instead (10.6 limitations).  

I second Lee's suggestion to write a post_uninstall script.  You can get a pretty good idea of what to kill off via Adobe's CC Cleaner tool (http://www.adobe.com/support/contact/cscleanertool.html), which seems pretty thorough.

Kris Lou
kl...@themusiclink.net

--

[Joey]

I had the same issue. To solve it I just ended up breaking up the package installers. Each app has its own package and I group together apps with munki manifests. I was trying to put flash pro + flash builder and photoshop + bridge + extension manager. When I separated those 2 packages into 5 packages, the uninstall through munki went fine. It's a little hard to manage updates (since you have to do each pacakage separately ) but using munki manifests for grouping them works better for us because we have a lot of one-off cases where someone needs their group of apps, plus 1 additional one that might be different for each person. Having individual installers and managing who gets which combinations of apps through munki ended up being easier.

[Martin van Diemen]

To uninstall the applications - that have been installed as a bundle - we need to add the uninstaller and make it available via optional_installs in the manifest. In this case the uninstaller would always available.

Maybe there is a better way by adding an extra uninstall method that would point to the Item Name that contains the uninstaller. In case an uninstall is required munki knows which uninstaller it needs. To make this uninstall method work would it be possible to expand uninstall_method with remove_item_name for example so we can link the uninstaller to the installer?

Do we have other possibilities?

Thanks,

Martin

[Gregory Neagle]

On Sep 13, 2013, at 11:05 AM, Martin van Diemen <martin.v...@gmail.com> wrote:

To uninstall the applications - that have been installed as a bundle - we need to add the uninstaller and make it available via optional_installs in the manifest.

Still not clear. You mean you are installing a suite, but removing individual applications?

In this case the uninstaller would always available.

Maybe there is a better way by adding an extra uninstall method that would point to the Item Name that contains the uninstaller. In case an uninstall is required munki knows which uninstaller it needs. To make this uninstall method work would it be possible to expand uninstall_method with remove_item_name for example so we can link the uninstaller to the installer?

Do we have other possibilities?

I still don't understand what things are working and what things are not.

Are you saying that Munki's current support for uninstalling Adobe CS5/5.5/6 items is failing for CC items?

If this is case, do you see different behavior when using the uninstall package generated by CCP?

-Greg

Thanks,

Martin

On Monday, September 9, 2013 4:42:50 AM UTC+2, gregn...@mac.com wrote:

On Sep 6, 2013, at 1:17 PM, Peter Bos <p_...@mac.com> wrote:

> I created a package installer with Adobe CCP where InDesign CC and Photoshop CC are added to.
> Munkiimport worked fine and installing the applications to a client also works fine.
> Uninstalling the package however doesn't work well. Only InDesign is uninstalled and Photoshop isn't.
>
> Other tests had the same result.

Do you see different behavior when using the uninstall package generated by CCP?

-Greg

>
> Does anyone had the same problem and solved this?
>
> regards,
> Peter

[sondjata]

Did anyone get the uninstall running? I just ran into this bug. The uninstaller removed nothing. Most importantly MUNKI has it unchecked in the optional installs but showed it installed. This is because of the "installs" items being present in /Library/application support/adobe/uninstall/. 

I guess the only solution is going to be removing the items via a post-uninstall script since I can't see how I can trigger the uninstaller created by the packager for a MUNKI based uninstall…..unless I can run:

 installer -pkg ?path/to/adobe/uninstaller/ -T / 

with the Adobe uninstaller sitting in a known location….

That might work...

[Gregory Neagle]

I have no access to any Adobe CC apps so can be of no help. Sorry!

-Greg

[sondjata]

No problem. I'm going to try out my mini idea and see if that works out and report back.

[Henning Kessler]

I prefer to install the uninstaller side by side with the installer package in a fixed location. by this the uninstall can be done by a pre or post install script. I had to do this to give our user the possibility to change the localization of the adobe apps. 

Henning

[sondjata]

Ok so  for anyone doing this here's what I did that works:

Created a "design suite" equivalent for our purposes but it will work regardless.

1) create install package with Adobe's packager. It creates and install build and an uninstall build.

2) import the install and uninstall build.

3) Zip the install build. Failure to do so will have MUNKI create an install Pkginfo file that will attempt to RUN the uninstaller. You don't want that. So zip the Uninstall pkg. I used Apple's package maker to install the zipped file to /Applications/Utilities/Adobe CC Uninstallers/.

4) in MUNKI set the uninstaller pkg as an update for the install pkg.

5) As a post install script. Unzip the installed Uninstaller zip file to the same directory.

6) as a preuninstall script run "installer -package /Applications/Utilities/Adobe CC Unintstallers/{name of uninstaller} -Target /

Now whenever you install Adobe CC the uninstaller will be in place. When you ask MUNKI to uninstall CC it automatically uninstalls all the other update items, including your uninstaller pkg. The uninstall pkg will uninstall and run it's pre-install script which properly wipes the Adobe CC install. Then the Adobe CC uninstall happens, which of course does nothing more than tell MUNKI that the suite shouldn't be checked as installed. 

Hope this helps any new people to MUNKI.

[Harry Fike]

Running the CCP generated uninstaller that is output in the build folder successfully uninstalls all the apps. If you look in the pkginfo generated when you import the CCP generated installer, the uninstallxml (under the adobe_install_info key) is incomplete as it only shows the first item from the optionalXML.xml from inside the install pkg. This is why the uninstall appears to fail, although it is successfully uninstalling that one app. I'm going to open an issue on google code as it appears to be an issue with how the getCS5uninstallXML function in adobeutils.py parses the CCP generated optionalXML.xml file.

-- 

Harry

[Gregory Neagle]

You can open the issue, but since I have no access to any CC apps, I personally cannot fix anything around installs/removals of Adobe CC products.

Perhaps someone else can fix this.

-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/d/optout.

[Harry Fike]

I've been looking through adobeutils.py and will also be providing a CCP generated optionalXML.xml file. It appears that the DeploymentInfo keys in the CCP optionalXML.xml file are no longer nested in the same key, but are now separated out into different parent keys... totally not using the correct terms, so I'll post some examples shortly.

-- 

Harry

[Harry Fike]

Here is a sanitized optionXML.xml and pkginfo file: https://gist.github.com/hfike/be05f9e729fe38f12333 For the pkginfo, you'll notice that the uninstallxml only contains one item. It appears that the change in structure of the optionXML.xml file causes an issue when the getCS5uninstallXML function in adobeutils.py (https://code.google.com/p/munki/source/browse/code/client/munkilib/adobeutils.py#151) iterates over the file.

-- 

Harry

[Harry Fike]

Issue opened here: https://code.google.com/p/munki/issues/detail?id=349 Please comment if you have access to CC!

Thanks,

-- 

Harry

[elfl...@hotmail.com]

Has any further investigation gone into this?

[Harry Fike]

Currently changed to a enhancement request. New home of the issue is here: https://github.com/munki/munki/issues/349 Hoping to get time to take another swing at this soon.

-- 

Harry

[Jason Hueske]

FWIW, the way I get around this issue is to deploy the Adobe CC Cleaner tool everywhere. It could be deployed as a required install I suppose (NOT an update_for as that would remove it too early), but it's tiny enough and useful enough that who's counting? I invoke it with the script here:

http://helpx.adobe.com/creative-suite/kb/cs5-cleaner-tool-installation-problems.html#enterprise

The argument as displayed on that page, with a space after =,  doesn't work. It must be:

--removeAll=CREATIVECLOUDCS6PRODUCTS

IME invoking this tool is sufficient to clean out the important licensing bits, and prepare the ground for another install. I have to follow it up with rm -rf's for the leftover /Applications and /Utilities folders. Not perfect but very fast, and I've used this with good results to automate upgrading/downgrading from CS6, as well as between different CC packages containing different sets of apps.

- Jason

[Gregory Neagle]

But how sad that this tool needs to exist...

-Greg

[Jason Hueske]

I'm not going to claim that doing this this way didn't give me a big old sad. I died a little inside while compiling the list of /Applications and /Utilities folder to rm -rf after the tool was done. You had ONE JOB!

- Jason

[MiqViq]

What about all those custom presets or additional plugins in Photoshop, InDesign which are in CC app directories?

I have had many cases where a simple rm -rf script will not be enough.

And it is quite complicated to replicate the uninstaller logic Adobe has (which saves 3rd party additions in app directories).


- MiqViq

[Jason Hueske]

Those get nuked by the rm -rf's.

¯\_(ツ)_/¯

In your case you're probably better off invoking the cleaner script alone, then trying your chances with installing over what is left over. I would imagine that Adobe's uninstaller logic is significantly replicated within the Cleaner tool.

- Jason

[MiqViq]

Anyone have a clue how to run those separate uninstallers in silent mode?

The ones that have symlinks in /Applications/Utilities/Adobe\ Installers and real location is in /Library/Application Support/Adobe/Uninstall?

I could not find any docs on that so probably it is not even possible.

I can launch them as root when a GUI session is on but hat is not a real solution...


- MiqViq