August 2009 - Installer-dev

[Mac OS X 10.5] Design bug in Installer.app
by Iceberg-Dev 31 Aug '09

31 Aug '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:mime-version :content-transfer-encoding:message-id:content-type:to:from:subject :date:x-mailer; bh=7aKrk1bp98cjtjkKIOgFJROKWKUXPV8t2MoeovDD2dQ=; b=aNS0bQrbvXjiIXAuGh5lCtZQzFy6EfsMpgCz8eIbIXZzlkzOr0Y23lkjFD+j0RMb4U FKfQ7SQcom/zI0HTY9Mb5eepCxn4R0I4w9kjqx5C/RY6dbm3mEx5iooDUUjWiwkrFw1k tP+j1+MBZJI5MIgeTOiIfsacRPxvMp+31050k= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:content-transfer-encoding:message-id:content-type:to :from:subject:date:x-mailer; b=KJVnSh9+GhbQwUJqfp+S/r9Qdi5UU/+gYGzvh/u+Z9GICtzX8yECyuFTdsXx35wIk4 1Tw7+3omPYamUHHZjMGSiZZWxy8MJE88c/a3sXD7Ib5f5Gx49rq4HL9ZeRVcIJSUBcUs EGWUvM5U3graZ12FN+nqEOw66GZhPSJtJAXuc= _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… There's a design bug in Installer.app on Mac OS X 10.5 when it comes to Installation Check script. If an Installation Script fails, returns a Fatal error but does not set an error 'message', Installer.app reports that there is no error message and then continue the installation process as if nothing was wrong in doing that. Installer.app should stop the installation process whenever an installation check script returns a fatal error EVEN IF the error message is not set. This email sent to site_archiver(a)lists.apple.com

1 0

Snow Leopard installer error - cannot copy scripts?
by Brant Sears 31 Aug '09

31 Aug '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On 10.6, it generates an error that says "Could not copy scripts." Thanks for any help. _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… Hi. I have a packager maker project (.pmdoc) that produces a .mpkg for my app and includes the another .pkg that is from another company. On 10.5, this project builds and produces a .mpkg. Also, on 10.6, I get a dialog that says "Resources Found" Installer interface resources were found in <other project file>. Would you like to use them for this install? This will replace any previously specified resources. I click "Do not use" every time, but it keeps asking me this over and over. The other package includes preflight and postflight scripts only. I tried deleting them, but I get the same error. When this gets invoked from my build script (which is a bash script), PackagerMaker throws an exception and I get something that looks like a core dump printed out: Mon Aug 31 14:30:22 ilovecm.local packagemaker[618] <Error>: kCGErrorInvalidConnection: CGSGetCurrentCursorLocation: Invalid connection Mon Aug 31 14:30:22 ilovecm.local packagemaker[618] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged. 2009-08-31 14:30:22.673 packagemaker[618:903] -[PMCLIFakeDocument alertDispatcher]: unrecognized selector sent to instance 0x209490 2009-08-31 14:30:22.675 packagemaker[618:903] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '- [PMCLIFakeDocument alertDispatcher]: unrecognized selector sent to instance 0x209490' *** Call stack at first throw: ( 0 CoreFoundation 0x98fd358a __raiseError + 410 1 libobjc.A.dylib 0x93c88f49 objc_exception_throw + 56 2 CoreFoundation 0x9901f9db -[NSObject (NSObject) doesNotRecognizeSelector:] + 187 3 CoreFoundation 0x98f7b026 ___forwarding___ + 950 4 CoreFoundation 0x98f7abf2 _CF_forwarding_prep_0 + 50 5 packagemaker 0x0009c0c3 0x0 + 639171 6 Foundation 0x9673cb65 __NSFireDelayedPerform + 537 7 CoreFoundation 0x98f3eeee __CFRunLoopRun + 6846 8 CoreFoundation 0x98f3cd34 CFRunLoopRunSpecific + 452 9 CoreFoundation 0x98f3cb61 CFRunLoopRunInMode + 97 10 Foundation 0x967b5b21 -[NSConcreteTask waitUntilExit] + 273 11 packagemaker 0x00034525 0x0 + 214309 12 packagemaker 0x00035809 0x0 + 219145 13 packagemaker 0x000333af 0x0 + 209839 14 packagemaker 0x00031596 0x0 + 202134 15 packagemaker 0x00031672 0x0 + 202354 16 packagemaker 0x0003ede2 0x0 + 257506 17 packagemaker 0x00030553 0x0 + 197971 18 packagemaker 0x0006a826 0x0 + 436262 19 packagemaker 0x00069e54 0x0 + 433748 20 packagemaker 0x00002c16 0x0 + 11286 21 packagemaker 0x00002bf5 0x0 + 11253 ) ./CreateInstaller: line 245: 618 Trace/BPT trap /Developer/ usr/bin/packagemaker --doc InstaLAN.pmdoc -o "$PACKAGE_FILE" What's up with this? How can I change the project so that it doesn't fail in this manner? This email sent to site_archiver(a)lists.apple.com

1 0

Re: 10.6 Upgrade kills permissions on Application Support folder for my app
by Clemmer, Everette 31 Aug '09

31 Aug '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: AconTTxexsPJWniIQemMdAolkMhPNgC88Uie Thread-topic: 10.6 Upgrade kills permissions on Application Support folder for my app _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: clarification re: Mac OS X standard directories inside a component’s hierarchy
by Iceberg-Dev 27 Aug '09

27 Aug '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:in-reply-to:references :mime-version:content-type:message-id:cc:content-transfer-encoding :from:subject:date:to:x-mailer; bh=UP3iRqf7ZzY9nYG5m39SckBw9YA3rptdPshkMCmbzms=; b=iWZ3BDA4+z4Lo2SGvZ1Kz1jvTTplKUaLxOAtLzKrDQtemxBLoOaJo+gc1ksBVB7cUw ufUAwvJ6UBcHW6bCAk8KcyPa4Xl5Pt1N7HFUAuFJVuwP5Heqvs+x7h80wod2dfyfNIMI o9/lKnxMWaKAAClcuHPMNuk/A6NUvRycG8t9g= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=in-reply-to:references:mime-version:content-type:message-id:cc :content-transfer-encoding:from:subject:date:to:x-mailer; b=FZdKHahrCuHbUQVSLCFKJd4btiIZ7aSvSRSN1oL0PYEDbwduJZ86+sqfIWUIa5WnUS iJUX634VAhYZhkVmwVs0NBrFUdZn3YG4B5oaqC+nhDdbRoyUWBSqC28MsPq5PZVZfB4e 1Mky6EtpB7u3yDGvR5SsbEslGeGL3+NjUGrgY= On Aug 27, 2009, at 12:52 AM, justin blecher wrote: * are my evaluations and suggestions for the fixing (hah!) the offending packages on the right track? (not like i'm interested in fixing them, i'm just trying to grok the concepts for my own packages.) Sure: What you should not do (if you can) is to allow overwriting of the permissions of these standard directories. right. well, by default the packages i'm creating in Iceberg don't have "allow overwriting of permissions" on, so i shouldn't have to worry about that, right? are you suggesting that it doesn't matter what the owner/group/permission bits are on any of the enclosing folders if they already exist? i'd expect for consistency/sanity's sake that one would want to make the permissions of the enclosing folders the same as what currently exists [on a reference system]. what if other packages were sloppy and messed with the perms (they had enclosing folders set to incorrect perms and enabled 'allow overwriting...')? just hope that the user will eventually run "repair permissions"? For instance: - /Library/Widgets Mac OS X 10.4: ./Library/Widgets 40775 0/80 Mac OS X 10.5: ./Library/Widgets 40755 0/0 - /Library/StartupItems Mac OS X 10.1: root:admin was fine Mac OS X 10.4: root:wheel was mandatory My $0.02 _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… On Wed, Aug 26, 2009 at 4:28 PM, Iceberg-Dev<dev.iceberg(a)gmail.com> wrote: On Aug 26, 2009, at 9:45 PM, justin blecher wrote: [...] * is my assumption/interpretaton -- anytime there are items that belong in a "standard directory", a separate package must be made for them, targeted to that standard directory -- correct? IMHO, this warning is just plain bullsh*t. ooookay. care to elaborate why you feel that way? :) o This would imply that you have almost to create one package for each component you want to install. Obviously if you just need to install one .app application in /Applications and you don't need to have it distributable through Apple Remote Desktop, you don't need an installer. But if you need to install an application, a kernel extension, a launchd script, some documentations, etc., you would end up with a lot of components when it's not needed. o Not all the standard directories are created by default depending on the version of the OS you are using. For instance, /Library/ StartupItems was not created by a clean install until Mac OS X 10.X X>=3. Other examples can be found easily. I have 2 in mind but I can't talk about it before tomorrow even though it's the 28th here. So let's say you need to install something into /Library/THISFOLDER where THISFOLDER is a standard directory created in version 2 of the OS but not in version 1 and you need to support both 1 and 2. I tend to believe the installer will fail to install on version 1 of the OS if you specify the default location to be /Library/THISFOLDER and if it works, then where is it going to find the correct permissions it needs to apply to this standard directory? o There is a minor bug related to custom folder icons when you set the default location to be a standard directory instead of /. o Apple does not follow this guideline and I'm not referring to the OS. The Apple Remote Desktop installation package does not follow this guideline. And the guys working on Apple Remote Desktop probably know a few things about installation. When in Rome, do as the Romans do, not as the Visitor Center recommends you to do. This somehow assumes that you are confident that no other packages have messed with them. The problem is that you can't forecast if the correct permissions are not going to change. Therefore if you are going to overwrite the permissions for a standard directory, use the permissions for the most recent release of the OS. Ideally, you should not have too. Installer.app should be clever enough to fix them when you install something inside them. This email sent to site_archiver(a)lists.apple.com

1 0

Re: 10.6 Upgrade kills permissions on Application Support folder for my app
by Don Montalvo 27 Aug '09

27 Aug '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Ryan McGann <rmcgann(a)mac.com> wrote: I have an application that needs a support folder in /Library/ Application Support. This folder is created when my installation package is run and has the following permissions: drwxrwxrwx 6 root admin 204 Aug 10 18:09 Foo When running the 10.6 upgrade to Snow Leopard from 10.5, the permissions get changed to: drwxr-xr-x 6 root admin 204 Aug 10 18:09 Foo This has the side effect of preventing the application from writing to the folder when run as a user other than root. Changing the permissions back to drwxrwxrwx after the upgrade fixes the problem, but I'd rather release a preemptive patch to fix this rather than dealing with it on the customer support side. Any suggestions? You can try storing your data in in /Users/Shared instead of Application Support. I'm not sure what the official recommendation is, but I'd take Apple changing the permissions behind your back as an unofficial recommendation, since it's obviously too late for them to change. ...note the section titled "Don’t Pollute User Space": Don _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… Ryan My two previous responses were bounced since my iPhone apparently can only send from my @me.com account but not from my subscribed @mac.com account. Listmom: should I unsubscribe/resubscribe? I commented that HOBOware (an application used by one of my clients to monitor/trend the temperature, humidity, etc., of their art storage areas) has the same issue. It was designed to be installed for a single user (it installs into ~/Library/Application\ Support), and assumed the user has admin rights. After discussions with the developer going over our managed environment (users are non-admins, AD/OD golden triangle environment), we came up with a solution that would allow the installer to put its stuff into the /Library/Application\ Support folder, then a login script would kick in once per user to copy stuff from /Library/ Application\ Support/HOBOware/ directory into the users' ~/Library/ Application\ Support/HOBOware/ folder so the application would reference the "user" domain data (the script would then delete itself). HOBOware obviously needs to be rewritten to respect/adhere to the Apple software distribution guidelines. Note how /Users directory (and /Users/Shared) should not be used for installs: http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Art… /apple_ref/doc/uid/TP40001411 http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Art… /apple_ref/doc/uid/TP40001411-111946 PS, thanks to the folks on this list (and a couple others) for the login script workaround. :) This email sent to site_archiver(a)lists.apple.com

1 0

Re: Advice on installing an Agent to the users home directory [SOLVED]
by Citizen 27 Aug '09

27 Aug '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On 26 Aug 2009, at 13:25, Citizen wrote: ------ #!/usr/bin/env bash echo $SCRIPT_NAME: launching TiptoeAgent exit 0 ------ Thanks, David Kennedy (http://www.zenopolis.com) _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… My new application includes a User Agent. I want to give the user the option to install this application in the system domain or the user domain. My second requirement was that the installer launches the Agent without a system restart or logout. I'm using PackageMaker 3 and targeting OS X 10.5 (Leopard) and later. Spurred on by Iceberg-Dev suggestion I came up with a solution. Using the same property list as before: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd "> <plist version="1.0"> <dict> <key>Label</key> <string>com.zenopolis.ApplicationAgent</string> <key>KeepAlive</key> <true/> <key>StandardErrorPath</key> <string>/Users/Name/Desktop/stderror.txt</string> <key>StandardOutPath</key> <string>/Users/Name/Desktop/stdout.txt</string> <key>ProgramArguments</key> <array> <string>-ROOTPREFIX-/Applications/ApplicationAgent.app/Contents/ MacOS/ApplicationAgent</string> </array> </dict> </plist> I now use the following script to change the -ROOTPREFIX- place marker and launch the Agent: if test -e ~/Library/LaunchAgents/com.zenopolis.TiptoeAgent.plist; then sed -iTemp 's|-ROOTPREFIX-|'$HOME'|' ~/Library/LaunchAgents/ com.zenopolis.TiptoeAgent.plist rm ~/Library/LaunchAgents/com.zenopolis.TiptoeAgent.plistTemp chown root:wheel ~/Library/LaunchAgents/com.zenopolis.TiptoeAgent.plist chmod 644 ~/Library/LaunchAgents/com.zenopolis.TiptoeAgent.plist launchctl load ~/Library/LaunchAgents/com.zenopolis.TiptoeAgent.plist elif test -e /Library/LaunchAgents/com.zenopolis.TiptoeAgent.plist; then sed -iTemp 's|-ROOTPREFIX-||' /Library/LaunchAgents/ com.zenopolis.TiptoeAgent.plist rm /Library/LaunchAgents/com.zenopolis.TiptoeAgent.plistTemp launchctl load /Library/LaunchAgents/com.zenopolis.TiptoeAgent.plist fi This email sent to site_archiver(a)lists.apple.com

1 0

Re: 10.6 Upgrade kills permissions on Application Support folder for my app
by Ryan McGann 27 Aug '09

27 Aug '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com drwxrwxrwx 6 root admin 204 Aug 10 18:09 Foo drwxr-xr-x 6 root admin 204 Aug 10 18:09 Foo Ryan _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… I have an application that needs a support folder in /Library/ Application Support. This folder is created when my installation package is run and has the following permissions: When running the 10.6 upgrade to Snow Leopard from 10.5, the permissions get changed to: This has the side effect of preventing the application from writing to the folder when run as a user other than root. Changing the permissions back to drwxrwxrwx after the upgrade fixes the problem, but I'd rather release a preemptive patch to fix this rather than dealing with it on the customer support side. Any suggestions? You can try storing your data in in /Users/Shared instead of Application Support. I'm not sure what the official recommendation is, but I'd take Apple changing the permissions behind your back as an unofficial recommendation, since it's obviously too late for them to change. This email sent to site_archiver(a)lists.apple.com

1 0

Re: clarification re: Mac OS X standard directories inside a component’s hierarchy
by justin blecher 26 Aug '09

26 Aug '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=+xY7IfZchTxYhyGhD4fkK+KiFSB6EyTTC+z1zO3rBos=; b=VtIavBOlnMkIB8cLge0RPH0NFwaj8qBjVarMudJzcrzQ2XEq5GRf7I6badDtg2rTWS eMsPQQjcFxMzcH1t2vdPVpn+fuGZ5tpaIxAngMi2uoONrZTk+sPEgIofrieib7jUKvBc CpckhUOiFWcLnfLfVKfHLvLAjGwE/IINwHj5A= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=kja4pDf42hNUxatJi7IM4S936KfRjTyL0bpUbrtD5dH+JCX6XRuU0Old4wNs8Gabqr PbwxIeFECti/ALxVC1XExlLxnU7l6OaACvoNfVmH6lXip1Rpxr9IIEES5Gz4Xroh9BD1 DW/pl0C9yHrhNcO1gAfK/s+MWWFk1DaJf7Nnw= On Wed, Aug 26, 2009 at 4:28 PM, Iceberg-Dev<dev.iceberg(a)gmail.com> wrote: > > On Aug 26, 2009, at 9:45 PM, justin blecher wrote: [...] >> * is my assumption/interpretaton -- anytime there are items that >> belong in a "standard directory", a separate package must be made for >> them, targeted to that standard directory -- correct? >> >> * are my evaluations and suggestions for the fixing (hah!) the >> offending packages on the right track? (not like i'm interested in >> fixing them, i'm just trying to grok the concepts for my own >> packages.) > > IMHO, this warning is just plain bullsh*t. ooookay. care to elaborate why you feel that way? :) > What you should not do (if you can) is to allow overwriting of the > permissions of these standard directories. > > This somehow assumes that you are confident that no other packages have > messed with them. right. well, by default the packages i'm creating in Iceberg don't have "allow overwriting of permissions" on, so i shouldn't have to worry about that, right? are you suggesting that it doesn't matter what the owner/group/permission bits are on any of the enclosing folders if they already exist? i'd expect for consistency/sanity's sake that one would want to make the permissions of the enclosing folders the same as what currently exists [on a reference system]. what if other packages were sloppy and messed with the perms (they had enclosing folders set to incorrect perms and enabled 'allow overwriting...')? just hope that the user will eventually run "repair permissions"? >> * what is the definitive list of "Mac OS X standard directories", or >> how can i generate it dynamically? > > You could find it by examining the Essentials.pkg packages from a Mac OS X > Install Disc. Pacifist can help. ok, got it. i ended up using good 'ole lsbom: lsbom -p MUGsf `pkgutil --bom /Volumes/Mac\ OS\ X\ Install\ DVD/System/Installation/Packages/Essentials.pkg` | grep '\./Library/' | grep ^d > essential_directory_listing.txt ...and then manually filtered the resulting list to get: drwxrwxr-x root admin ./Library/Address Book Plug-Ins drwxrwxr-x root admin ./Library/Application Support drwxrwxr-x root admin ./Library/Application Support/Apple drwxrwxr-x root admin ./Library/Application Support/Macromedia drwxrwxr-x root admin ./Library/Application Support/Mozilla drwxrwxr-x root admin ./Library/Application Support/ProApps drwxrwxr-x root admin ./Library/Audio drwxrwxrwt root admin ./Library/Caches drwxrwxr-x root admin ./Library/ColorSync drwxrwxr-x root admin ./Library/Components drwxrwxr-x root admin ./Library/Compositions drwxrwxr-x root admin ./Library/Contextual Menu Items drwxrwxr-x root admin ./Library/Dictionaries drwxr-xr-x root wheel ./Library/Filesystems drwxrwxr-x root admin ./Library/Fonts drwxrwxr-x root admin ./Library/Frameworks drwxrwxr-x root admin ./Library/Image Capture drwxrwxr-x root admin ./Library/Input Methods drwxrwxr-x root admin ./Library/Internet Plug-Ins drwxr-xr-x root wheel ./Library/LaunchAgents drwxr-xr-x root wheel ./Library/LaunchDaemons drwxrwxr-x root admin ./Library/Logs drwxrwxr-x root admin ./Library/Mail drwxrwxr-x root admin ./Library/Modem Scripts drwxrwxr-x root admin ./Library/PDF Services drwxrwxr-x root admin ./Library/Perl drwxr-xr-x root wheel ./Library/PreferencePanes drwxrwxr-x root admin ./Library/Preferences drwxr-xr-x root admin ./Library/Preferences/SystemConfiguration drwxrwxr-x root admin ./Library/Printers drwxrwxr-x root admin ./Library/QuickLook drwxrwxr-x root admin ./Library/QuickTime drwxrwxr-x root admin ./Library/Ruby drwxrwxr-x root admin ./Library/Screen Savers drwxrwxr-x root admin ./Library/Scripts drwxrwxr-x root admin ./Library/Security drwxrwxr-x root admin ./Library/Spotlight drwxr-xr-x root wheel ./Library/StartupItems drwxrwxr-x root admin ./Library/Updates drwxrwxr-x root admin ./Library/User Pictures drwxrwxr-x root admin ./Library/WebServer drwxrwxr-x root admin ./Library/iTunes ... which is good enough to guide me in setting the perms in my enclosing folders (if i choose to do so... still researching this). -justin _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: clarification re: Mac OS X standard directories inside a component’s hierarchy
by Iceberg-Dev 26 Aug '09

26 Aug '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:in-reply-to:references :mime-version:content-type:message-id:cc:content-transfer-encoding :from:subject:date:to:x-mailer; bh=NEDYg2TgORIbhn5qypC17N+mWrTzafaw9zc+wWpt3LA=; b=rFIopCgQuUNHLFQUIJSGAJZ1LTfPvIQNGxFy4k3hE0Er4e0/WQZiZj/3LSRbXQ4yHj fBM39AtavZrTpsUMl2XU6x11gLjzTc35fhUOpRNF/WOuPPiFZAWjJiG9pYWPaOp/DpQY j2W3ySiL/U5PYFAcs9FKV/4sYjUbQEPU98lPA= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=in-reply-to:references:mime-version:content-type:message-id:cc :content-transfer-encoding:from:subject:date:to:x-mailer; b=XuWicFZIuA4cP5xvI1piI+FMjWX3IURP2h1OWqrs+LNWO4NYnl99q9YUaFcBWPy8+h bVHJwEBJPvn7UkW0DWl568+rK0uinxfRSJHfwpyRyfOX1Msdo9fhAMc50vapw3fbap7Q lsT4P1QdrWikL6iq9qJYQMRwowguxUzVY/oNE= On Aug 26, 2009, at 9:45 PM, justin blecher wrote: greetings everyone, i'm new around these parts and currently wrestling with the concepts and best practices for evaluating existing packages, repackaging non-pkg installers, and rolling out InstaDMG-created images for < 30 macs i have the pleasure of [part-time] managing. today my question centers around this quote: Important: Never include Mac OS X standard directories inside a component’s hierarchy. That is, do not reflect any standard part of the Mac OS X file system (in any of the file system domains) inside your component’s structure. [...] here's my real questions: * is my assumption/interpretaton -- anytime there are items that belong in a "standard directory", a separate package must be made for them, targeted to that standard directory -- correct? * are my evaluations and suggestions for the fixing (hah!) the offending packages on the right track? (not like i'm interested in fixing them, i'm just trying to grok the concepts for my own packages.) IMHO, this warning is just plain bullsh*t. * what is the definitive list of "Mac OS X standard directories", or how can i generate it dynamically? What you should not do (if you can) is to allow overwriting of the permissions of these standard directories. This somehow assumes that you are confident that no other packages have messed with them. You could find it by examining the Essentials.pkg packages from a Mac OS X Install Disc. Pacifist can help. _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Advice on installing an Agent to the users home directory
by Iceberg-Dev 26 Aug '09

26 Aug '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:in-reply-to:references :mime-version:content-type:message-id:cc:content-transfer-encoding :from:subject:date:to:x-mailer; bh=680Tebuvime/bl/l6wc08umPHa2Rn946FuAvFuQOGDE=; b=vbBgtCNEr4eV6b7eRoqDm00GoK4joWf6gPd8jwpCHjq3NTYegqZIXnVWcBw3aoiy7n v7aW9aIr0sAWHnS526rRY6yeH3pktvtTX1jzISaOjbwEFHYe1NPzfO4rq4RCRli+qwsl 8PdZ5Q6y4FZ9Ou0ZpsdZSRG8069MGnfNQfACY= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=in-reply-to:references:mime-version:content-type:message-id:cc :content-transfer-encoding:from:subject:date:to:x-mailer; b=UH2M+rxHV2zQUz64RKu46CAU/BoIQw3aCUML2+ZWPk1GpaNMvo2/sueIU3RyPC7eTt Al9L+gtpTuurS57/LZIkcbX5qxP2s7MxF1F6sXLvFr+Kz8orTK7XVqxef3J+pWU9UxuE ENSc1y2mlOki9RH905W9K7+ul7GxDyS4UVle8= On Aug 26, 2009, at 2:25 PM, Citizen wrote: Hello, Use the $USER env var? _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… [...] For the User Domain, the perl command does not work. The result for this is the path "/Library/LaunchAgents/ com.zenopolis.ApplicationAgent.plist". What I was attempting to get was the path "/Users/username/Library/LaunchAgents/ com.zenopolis.ApplicationAgent.plist". Is this general approach correct? Do I just need to keep searching and work out the right scripting voodoo? Or is this likely to be a dead end anyway? Are any of you tackling this same requirements in a completely different way? The following two attempts lead me to believe that I needed to set an absolute path in the Application Agent Property List: * I've tried replacing -ROOTPREFIX- for the User Domain with "~". The console showed the error: posix_spawnp("~/Applications/ ApplicationAgent.app/Contents/MacOS/ApplicationAgent", ...): No such file or directory. * I've also tried making the ProgramArguments value in the Agent Property List a relative path (../../Applications/ ApplicationAgent.app/Contents/MacOS/ApplicationAgent), but this did not work in the User Domain. The console showed the error: posix_spawnp("../../Applications/ApplicationAgent.app/Contents/ MacOS/ApplicationAgent", ...): No such file or directory. This email sent to site_archiver(a)lists.apple.com

1 0