Re: [Gimp-print-devel] macos uninstaller issues

[Matt B. <wal...@ma...>]

> On Feb 9, 2019, at 8:28 PM, Matt Broughton <wal...@ma...> wrote:
> 
> 
> 
>> On Feb 9, 2019, at 5:58 PM, Robert Krawitz <rl...@al...> wrote:
>> 
>> On Sat, 9 Feb 2019 17:38:15 -0800, Matt Broughton wrote:
>>> I am pulling this snippet from the macos gutenprint52+usb backend thread.  I think the discussion on the uninstaller would get buried otherwise.
>>> 
>>>>> I will try to make a post about why there is so much troubler with out uninstaller.  I got reminded of some of the nasties Apple tends to do with installs and using the Migration Assistant.  Moving to a new laptop reminded me of the issues.  My old laptop got some water on the keyboard and sparks started flying.  I am glad that I keep two backups.
>>>> 
>>>> I'd like to better understand the uninstaller situation.  That does
>>>> seem to cause problems.
>>> 
>>> I'll describe the current situation.  Problems from OS X 10.7 and before are similar but have some other specific issues.
>> 
>> Thanks for this solution.
>> 
>>> Every time you install software on macos by using an installer, as opposed to drag and drop, a receipt for what was installed and where it was installed is recorded in an invisible directory.  I am sure Linux and Windows do similar things.  The uninstaller has always relied on using  this receipt to find out what Gutenprint installed and where.  The list of files are then removed and the receipt removed.   This has been the practice since Mac OX 10.3.x.
>> 
>> Linux, "it's complicated".  Different distributions have different
>> package managers (Debian and its derivatives such as Ubuntu use dpkg
>> and .deb files; Red Hat, SUSE, and their derivatives use RPM (although
>> the RPMs, while of the same format, are not entirely mutually
>> compatible), and on just about any distribution you can install things
>> from source without any package management at all beyond
>> configure/cmake,make,make install.
>> 
>>> Currently, doing a system upgrade such as macos 10.12.x to macos 10.14.x leaves this receipt and the software files intact and no problem is encountered.  The Gutenprint drivers work fine and the receipt is left in place.  If the user uses Migration Assistant however, all bets are off.  Migration will remove the software receipts for *all* third party software.  Now when you try to run the uninstaller, it doesn't find any receipt and reports that there is nothing to remove.  This is why we recommend reinstalling the software and then run the uninstaller again.  This is contrary to common sense but is probably the easiest and safest way to proceed.  We could always tell those that need to remove the software to delete a subdirectory in the /Library directory.  In my mind, files in the /Library is a bit close to telling someone to remove system software.
>> 
>> Can we inspect what's in /Library (or wherever) and determine that
>> it's ours and delete it?  Or do a pseudo-install ourselves as part of
>> the uninstall?  That feels like a real shot in the dark, but...
> 
> The simplest solution is to just remove the  /Library/Printers/Gutenprint.printerDriver directory.  That would leave only some symlinks.  That is where everything is located.  There are symlinks that point to the executables, but those would be relatively harmless to leave in place.
> 
>> But this sounds like a rather serious problem with Migration
>> Assistant; what do other third party packages do?
> 
> My guess is that vendors like Epson, Microsoft, and the like aren't that concerned or are unaware of the situation.  Still others don't provide any sort of uninstaller.
> 
>>> I can't think of an easy alternative to using the software receipt to find what needs to be removed.  The uninstaller is meant to work for all installations of Gimp-Print and Gutenprint going back to Mac OS X 10.3.  That pretty much precludes just including a file with the distribution that contains the files to be removed.  There have been and probably will be changes in file names and locations that might cause problems using this method.  If there are any other methods that seem reasonable, we should explore them. 
>> 
>> How far back do we need the uninstaller to work?  Can we release a new
>> version of the uninstaller that handles this situation, but only from
>> 10.6 (oldest currently supported version of Gutenprint)?
> 
> 
> I will have to check back to see when Apple made the change in dealing with receipts and how far back we need or should go.  More importantly woulds be the point that we started using only the one directory in /Library/Printers for our software.  We had been using the /usr structure before that.  Apple suddenly blacklisted that directory and we changed.  There is a long story why we never used the /usr/local/usr structure.
> 
>>> It is probably worth noting that the current installer for Gutenprint does an uninstall of the old software prior to installation of the new software.  If that part of the install fails, it does so quietly, with the assumption that whatever is currently being installed will overwrite the old files.
>> 
>> Within 5.2, that's mostly true.  The exceptions are probably largely
>> harmless, other than being a small resource leak; pretty much all that
>> matters comes from the root of printers.xml.  Going from 5.2 to 5.3,
>> that won't be true; the files go in a different root directory (5.3
>> vs. 5.2), although even there it all starts from known root files and
>> what they refer to.

Ads it turns out, the installer has a very robust uninstaller script that I believe covers all cases.  I copied that and upped the authority to root by using sudo for all the cases where `/bin/rm -rf ` are found.  If you want full testing on it, I won't be able to get to it until the end of the month.  I should have some time then and access to my older computers where I can test it on Mac OS X 10.3.x through 10.6.x as desired.  An alternative is to just change the new script to have an extension of .command and it becomes a double click format.

Is there a way to have someone change a script to get an actual binary that could be signed?  Apple's security is getting tighter and tighter.  It is getting more and more cumbersome to use non-signed applications.
Matt

--
Matt Broughton
wal...@ma...