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 you can't put symlinks in /S/L/E, we could put the kext in /sw somewhere, and use daemonic to manually load the kext at startup. Also, this way when a user removes the package, we don't have to remove the kext. We can just replace the load-at-startup script with a delete-at-startup script, and leave the kext sitting around until reboot.
Dave
PGP.sig
Description: This is a digitally signed message part
