.framework files left over after self service uninstall

[conor]

Hi,

Have searched the forums for this but couldnt find an answer so assume its something wrong with my process. Was testing Self Service uninstalls yesterday and noticed that when trying to uninstall self created pkg files that they are leaving behind some .framework files. Namely:

Growl.framework
Sparkle.framework
NMSSH.framework

I have confirmed that these files are in the pkg when it is bundled and installed, so they should be removed on installation too aiui

Has anyone come across this and if so do they know where I have gone wrong?

Thanks

[mm2270 · Accepted solution]

I assume you're using an indexed package that you specify in an uninstall action for this? If so, my suggestion is to not use that. It's never been 100% reliable. I've seen this problem for years now and as such stopped using that functionality. The problem I believe is that if any files within the application bundle change in any way from the original deployment, like an update, the index no longer sees them as files to be removed. I think the indexing uses more than simply the file name and path. It probably also compares the sizes and/or modification dates or something. So for example, if you bundle up Adobe Acrobat Reader DC and deploy it, if it gets updated later through Adobe's update mechanism or otherwise, files within the app bundle get changed and the index of your original package no longer matches up.

At least that's my theory but that could be entirely wrong. All I know is this leaving cruft behind after an uninstall has been a problem for years now, so I simply stopped using it.

Instead, I would consider a simple scripted process. Something like the following should be able to remove Self Service from a system

#!/bin/sh

rm -R "/Applications/Self Service.app"

If you wanted to, you could throw in a line that would force quit Self Service if it's open before it deletes it, but I don't know the specifics of when you plan on using this.

[mm2270 · Accepted solution]

I assume you're using an indexed package that you specify in an uninstall action for this? If so, my suggestion is to not use that. It's never been 100% reliable. I've seen this problem for years now and as such stopped using that functionality. The problem I believe is that if any files within the application bundle change in any way from the original deployment, like an update, the index no longer sees them as files to be removed. I think the indexing uses more than simply the file name and path. It probably also compares the sizes and/or modification dates or something. So for example, if you bundle up Adobe Acrobat Reader DC and deploy it, if it gets updated later through Adobe's update mechanism or otherwise, files within the app bundle get changed and the index of your original package no longer matches up.

At least that's my theory but that could be entirely wrong. All I know is this leaving cruft behind after an uninstall has been a problem for years now, so I simply stopped using it.

Instead, I would consider a simple scripted process. Something like the following should be able to remove Self Service from a system

#!/bin/sh

rm -R "/Applications/Self Service.app"

If you wanted to, you could throw in a line that would force quit Self Service if it's open before it deletes it, but I don't know the specifics of when you plan on using this.

[conor · Accepted solution]

@mm2270 Hey thanks,

Yeah i figured this would probably be the case, I thought of a way round it in the mean time by moving the application files to /tmp/ then clearing out that..

Just to clarify, this was removing an application WITH self service, not trying to remove self service itself :P

[mm2270]

Haha. Ok, that makes more sense. I was wondering why you'd want to remove Self Service, but didn't ask.
Anyway, whether it's removing Self Service or something else, the problem seems to happen fairly regularly, so there's always a bit of extra cleanup to do afterwards.

[conor]

Yeah looking at it now i can see where the confusion came from.

Thanks for the help though, much appreciated