April 2008 - Installer-dev - lists.apple.com

Maximize button in installer window is disabled.
by Damodar Shenoy 24 Apr '08

24 Apr '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.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.… This email sent to site_archiver(a)lists.apple.com

1 0

Installer reporting wrong final size - storing old receipt info somewhere
by A. Brooks Hollar 22 Apr '08

22 Apr '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: Acikoi3LbBVFqhCVEd2wywAX8tAOVQ== Thread-topic: Installer reporting wrong final size - storing old receipt info somewhere User-agent: Microsoft-Entourage/11.3.3.061214 INFO: On my development machine once I select a Volume to install my app to it reports the size of the final install incorrectly. This appears to be because the OS thinks I already have it installed and is just "being helpful." I have verified that there is no receipt in either the /Library/Receipts folder or in the dB by calling, "pkgutil --packages" I assume this is a receipt issue because if I change the CFBundleIdentifier string in package.pkg/Contents/Info.plist then it reports the correct size. Questions: 1) why am I seeing this behavior? 2) is there some other place I should check for receipts? 3) what is a good way to clean up my development box so that I don't run into this in the future? Thanks! -ab _______________________________________________ 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: Dir creation from installer tool is always locked
by Mike 19 Apr '08

19 Apr '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.12 (Macintosh/20080213) I was finally able to get it to work from the postinstall script itself: USER="$HOME" LIBRARY_RECEIPTS_DIR="/Library/Receipts/" USER_LIBRARY_RECEIPTS_DIR="${USER}${LIBRARY_RECEIPTS_DIR}" mkdir -m 777 "${USER_LIBRARY_RECEIPTS_DIR}" The issue is not with the tool AFAIK, it's in these APIs. Stéphane Sudre wrote: On Apr 19, 2008, at 12:46 AM, Mike wrote: Stéphane Sudre wrote: On Apr 19, 2008, at 12:09 AM, Mike wrote: No matter what I do, and no matter what permissions I give to subpackages in my metapackage, when I have my postinstall script run a CoreFoundation tool that I bundle in my installer, any directories created by my tool at postinstall time are created with 'system' as being the owner, and hence such directories are locked. How do I create a directory from within a postinstall tool that is unlocked? I had assumed that since the package was running with root permissions and since the installer has authorization, the directory would be created with unlocked permissions. Attempting to set the owner or group or permissions on any created dirs after they are created also fails. Stupid questions of the day: - Which API and methods do you use to create your directory? - Which API and methods do you use to to change the owner, group or permissions? I tried both the NSFileManager methods and Carbon methods such as FSCreateDirectoryUnicode and -fileAttributesAtPath:traverseLink: and -changeFileAttributes:atPath. Those all fail apparently because the tool I launch is running with the wrong owner or permissions. I was unaware of the -m option for mkdir. For some reason postinstall runs with adequate permissions, but any sub-binaries it launches don't. I've never been able to use the NSFileManager of FSCatalogInfo API to change the permissions or owners of a file/directory in 7 years. I will avoid the rant on NSFileManager and just say that I always use the chown and chmod BSD C methods because they just work. My guess is if I went to all the trouble writing a real helper tool, and jumped through all the Apple hoops for setting it up and executing it properly, the NSFileManager & Carbon calls would work. But who would want to go to all that trouble when one can just add a few lines to the postinstall and let the installer handle the rest. _______________________________________________ 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: Dir creation from installer tool is always locked
by Stéphane Sudre 19 Apr '08

19 Apr '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com USER="$HOME" LIBRARY_RECEIPTS_DIR="/Library/Receipts/" USER_LIBRARY_RECEIPTS_DIR="${USER}${LIBRARY_RECEIPTS_DIR}" mkdir -m 777 "${USER_LIBRARY_RECEIPTS_DIR}" The issue is not with the tool AFAIK, it's in these APIs. _______________________________________________ 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 Apr 19, 2008, at 12:46 AM, Mike wrote: Stéphane Sudre wrote: On Apr 19, 2008, at 12:09 AM, Mike wrote: No matter what I do, and no matter what permissions I give to subpackages in my metapackage, when I have my postinstall script run a CoreFoundation tool that I bundle in my installer, any directories created by my tool at postinstall time are created with 'system' as being the owner, and hence such directories are locked. How do I create a directory from within a postinstall tool that is unlocked? I had assumed that since the package was running with root permissions and since the installer has authorization, the directory would be created with unlocked permissions. Attempting to set the owner or group or permissions on any created dirs after they are created also fails. Stupid questions of the day: - Which API and methods do you use to create your directory? - Which API and methods do you use to to change the owner, group or permissions? I tried both the NSFileManager methods and Carbon methods such as FSCreateDirectoryUnicode and -fileAttributesAtPath:traverseLink: and -changeFileAttributes:atPath. Those all fail apparently because the tool I launch is running with the wrong owner or permissions. I was finally able to get it to work from the postinstall script itself: I was unaware of the -m option for mkdir. For some reason postinstall runs with adequate permissions, but any sub-binaries it launches don't. I've never been able to use the NSFileManager of FSCatalogInfo API to change the permissions or owners of a file/directory in 7 years. I will avoid the rant on NSFileManager and just say that I always use the chown and chmod BSD C methods because they just work. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Dir creation from installer tool is always locked
by Mike 18 Apr '08

18 Apr '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Stupid questions of the day: - Which API and methods do you use to create your directory? I was finally able to get it to work from the postinstall script itself: USER="$HOME" LIBRARY_RECEIPTS_DIR="/Library/Receipts/" USER_LIBRARY_RECEIPTS_DIR="${USER}${LIBRARY_RECEIPTS_DIR}" mkdir -m 777 "${USER_LIBRARY_RECEIPTS_DIR}" Stéphane Sudre wrote: On Apr 19, 2008, at 12:09 AM, Mike wrote: No matter what I do, and no matter what permissions I give to subpackages in my metapackage, when I have my postinstall script run a CoreFoundation tool that I bundle in my installer, any directories created by my tool at postinstall time are created with 'system' as being the owner, and hence such directories are locked. How do I create a directory from within a postinstall tool that is unlocked? I had assumed that since the package was running with root permissions and since the installer has authorization, the directory would be created with unlocked permissions. Attempting to set the owner or group or permissions on any created dirs after they are created also fails. - Which API and methods do you use to to change the owner, group or permissions? I tried both the NSFileManager methods and Carbon methods such as FSCreateDirectoryUnicode and -fileAttributesAtPath:traverseLink: and -changeFileAttributes:atPath. Those all fail apparently because the tool I launch is running with the wrong owner or permissions. I was unaware of the -m option for mkdir. For some reason postinstall runs with adequate permissions, but any sub-binaries it launches don't. Argh. _______________________________________________ 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: Dir creation from installer tool is always locked
by Stéphane Sudre 18 Apr '08

18 Apr '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Stupid questions of the day: - Which API and methods do you use to create your directory? _______________________________________________ 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 Apr 19, 2008, at 12:09 AM, Mike wrote: No matter what I do, and no matter what permissions I give to subpackages in my metapackage, when I have my postinstall script run a CoreFoundation tool that I bundle in my installer, any directories created by my tool at postinstall time are created with 'system' as being the owner, and hence such directories are locked. How do I create a directory from within a postinstall tool that is unlocked? I had assumed that since the package was running with root permissions and since the installer has authorization, the directory would be created with unlocked permissions. Attempting to set the owner or group or permissions on any created dirs after they are created also fails. - Which API and methods do you use to to change the owner, group or permissions? This email sent to site_archiver(a)lists.apple.com

1 0

Dir creation from installer tool is always locked
by Mike 18 Apr '08

18 Apr '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Thanks, Mike _______________________________________________ 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.… No matter what I do, and no matter what permissions I give to subpackages in my metapackage, when I have my postinstall script run a CoreFoundation tool that I bundle in my installer, any directories created by my tool at postinstall time are created with 'system' as being the owner, and hence such directories are locked. How do I create a directory from within a postinstall tool that is unlocked? I had assumed that since the package was running with root permissions and since the installer has authorization, the directory would be created with unlocked permissions. Attempting to set the owner or group or permissions on any created dirs after they are created also fails. This email sent to site_archiver(a)lists.apple.com

1 0

Xcode 2.5 PackageMaker on Leopard - command line problem
by Graham Westlake 18 Apr '08

18 Apr '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thanks, Graham Westlake Sibelius Software _______________________________________________ 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.… We have a shell script which we've been using to create updater packages for our app. The PackageMaker command line looks like this: $PACKAGEMAKER_COMMAND -build -p "./MyApp.pkg" -f "./package_contents" -b "/tmp" -s -ds -v -r "./install_resources" i "./Info.plist" -d "./ Description.plist" where PACKAGEMAKER_COMMAND=/Developer/Applications/Utilities/ PackageMaker.app/Contents/MacOS/PackageMaker. This works perfectly on 10.4 with Xcode 2.5. In order to use the script on a 10.5 machine with minimum impact, I installed Xcode 2.5 and changed PACKAGEMAKER_COMMAND thus: PACKAGEMAKER_COMMAND=/Xcode2.5/Applications/Utilities/PackageMaker.app/ Contents/MacOS/PackageMaker However this apparently identical command fails with "The package could not be created because of the following errors: No package identifier specified". Does anyone know what might cause this? The package identifier is correctly specified in the Info.plist, of course. This email sent to site_archiver(a)lists.apple.com

1 0

Automator workflow shell script error when run from PackageMaker 3.0.1
by Bryan S. Lee 15 Apr '08

15 Apr '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: AcifEI++z2YLeUf83UKZv5a88YmOfQ== Thread-topic: Automator workflow shell script error when run from PackageMaker 3.0.1 User-agent: Microsoft-Entourage/12.1.0.080305 Interesting tidbit that took a while to figure out. Thought I'd throw it to the listserve for info. I have an Automator app I built that automatically configures one of the types of wireless here on our campus. One of the first steps it does is run a shell script that calls an osascript command (applescript) to run another command with admin rights if you aren't root. Then the Automator actions do the setup. Runs fine as an individual app. Put it in PackageMaker and set it to open the app (with the open file automator command in 10.5 dist package) after installing and it would glitch out on me. Also tried as a postflight script to engage the automator app, didn't work. Finally narrowed it down to the command to 'touch' a file to turn on assistive devices so that the automator app would run correctly. If I removed that part (and made sure assitive support was on) it ran fine. So I broke the shell script out of the automator app, set it up as a postflight script (which I'm guessing PackageMaker is doing as root, and skips the osascript command to sudo touch the necessary file). Then open the automator file. Works fine now. I'm guessing PackageMaker didn't like the osascript command (calling Applescript and requiring a login). When it engages the Automator app, I don't think the app is running as root at that point, whereas a post-script does. -- Bryan S. Lee Information Resource Consultant II Computer Support Services Clemson Computing and Information Technology Clemson University bl(a)clemson.edu ACHDS 10.4, MCP NTS/NTW _______________________________________________ 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: Bug in the documentation or in Apple's own packages
by Bill Coderre 14 Apr '08

14 Apr '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Apr 14, 2008, at 2:17 PM, Stéphane Sudre wrote: According to the "Distribution Definition Reference" documentation, the version attributed of pkg-ref is _Required_. Strangely enough, iLifeSupport82-8.2.dist does not provide this piece of information and AFAIK, this "package" can be installed. So either the documentation is incorrect or the package is incorrect and the Installation Framework does not respect the format. I write that script. The pkg-refs are filled in by an automated build process. In what I see, they seem to be filled in. Stephane, why don't you email me off-list with an example or something and I'll look into it. _______________________________________________ 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