site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com On Sun, Feb 8, 2009 at 7:38 PM, Eli Bach <ebach2@gmail.com> wrote:
On Feb 8, 2009, at 7:18 PM, Brent Burton wrote:
OK, this is a huge reason to not use a postinstall-based technique. I agree, how else can a real uninstaller begin to work if we're hacking the process?
I would say this isn't exactly a great reason, because Apple has had 10 years of complaints about not having an uninstaller of any kind. From going to WWDC, I have never heard Apple even hint about ever adding such functionality (other than, file a bug report and we'll consider it).
So it's up to individuals to create uninstallers for their own setup, which can be quite straightforward to create, and doesn't depend on what is listed in the Package to do it's work. You would need to do this anyway, to clean up auxiliary files, such as preferences or cache/data files that are created when your application runs.
Greg and I have been having this discussion for a while now, and he has put together some really interesting code to try to automate the uninstallation process for packages. This isn't the biggest reason for me as someone who deals with packages every day and has to mange many many thousands of Macs though, but it is closely related. If developers continue to do hacky things with regard to destinations (and I've seen Apple people suggest this on this list, something I strongly disagree with) then it not only makes such tools well nigh impossible to develop, but it makes auditing and troubleshooting incredibly difficult. To take a simple example... If you want to make packages of Ruby modules that work on 10.4 and 10.5, you usually want the destination to be /usr/lib/ruby/site_ruby/1.8. On 10.4 this is a directory. On 10.5 it is a symlink. We rely heavily upon Ruby for our internal management systems, and there are many Ruby packages out there that install to /usr/lib/rub/site_ruby/1.8, but don't follow symlinks, breaking all existing Ruby modules in the process of wiping out the symlink. Trying to audit which packages are causing these problems is rather difficult when the bom doesn't actually contain the true destination. We have to deal with problems like this every day. Correlating dates in /Library/Receipts or installer logs with incidents is not my idea of a good time. _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com