Installing Preference Panes / Non-admin user issues
site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com Hello List, Help, hints and pointers are greatly appreciated Alex _______________________________________________ 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... initially, I stumbled upon the problem of updating a _loaded_ preference pane (1). Also, I would like to support 10.2, which does not include the "double-click" install for preference panes. Currently, my solution is to use an installer with a preupdate script that will quit the System Preferences and make sure my deamon (2) is shut down properly (3). This brought me to problem two: Installing a user's home directory. I am working around that with a postflight script that will move the Preference Pane from /tmp/ to ~/Library/ PreferencePanes But this is not my real problem (but I gladly read interesting comments, if you have them). Here is the problem: *** The Main Question: If a non-admin user tries to install the software, the installer can not copy the receipt into /Library/ Receipts due to permission problems. It works on admin accounts. I do not want to ask for admin privs, because my app has no need for them, and any user should be able to install the software. Besides, I tell users to scrutinize every piece of software that asks for admin priviledges, and while I do not mind scrutiny on my app users should see as clearly as possible that it does no evil. (1) http://lists.apple.com/archives/cocoa-dev/2005/Jul/msg00376.html (2) Technically, this is just a faceless background app that is started as a login item (3) If the Preference Pane was updated when loaded, I could then shutdown the old deamon and load the new one. However, as the pref pane and the daemon always must have the same version number, the old, not updated Pref Pane tries to communicate with the wrong daemon. First thing they do is exchange version numbers, and this of course fails This email sent to site_archiver@lists.apple.com
participants (1)
-
Alexander von Below