Re: Installing command line tools
Re: Installing command line tools
- Subject: Re: Installing command line tools
- From: Nigel Kersten <email@hidden>
- Date: Mon, 9 Feb 2009 11:49:26 -0800
On Sun, Feb 8, 2009 at 7:38 PM, Eli Bach <email@hidden> 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden