On Thu, Feb 12, 2004 at 11:05:13PM +0900, Peter O'Gorman wrote:
> 
> 3) would not install anything in /System/Library/Extensions, but would
> install somewhere in /sw and in a postinstscript add a symlink. This way a
> user who does sudo rm -rf /sw would be left with a dangling symlink in
> /System/Library/Extensions, but would not otherwise "damage" a users system.

Apple has gotten really draconian about how kexts can be installed
on the system.  I believe the kext actually has to be in /S/L/E, and
can't be a symlink.  I'll need to test, but I'm pretty sure a symlink
won't suffice.  I'll also go ask the kext folks how they would like
to see such a situation handled.

Some people also raised concerns about the uninstall case of the kext.
Many kexts have problems unloading, so doing a kextunload may (or may not)
cause a kernel panic.  For the short term, I think just having the
kext removed would suffice (along with any appropriate user warnings).
We could even rebuild the mkext cache for them after removing the kext,
just to make sure it won't load on the next reboot.

If there get to be a few kexts in fink, adding infrastructure to handle
this case would probably be good.  Having some way to let the package 
know whether to attempt an unload or not would be nice, but it's probably
not worth going too far down that road until it's actually an issue.

I'm fine with adding tons of user warnings and such.  I never listen 
to those anyway.  =)  Requiring interaction (with the default to abort)
would be fine as well.  Debian has many instances of that.  There's a
lot of cases where the user needs to actually pay attention, and if 
they are just picking the defaults, it's safe to assume they aren't.

Rob



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to