July 2007 - Installer-dev - lists.apple.com

Re: Installer plugins on 10.3
by Bill Coderre 24 Jul '07

24 Jul '07

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.… On Jul 24, 2007, at 12:10 AM, Mike wrote: So how does one then go about creating any kind of a custom installer using Packagemaker on a 10.3 system? In 10.3, you can add custom code at InstallationCheck, VolumeCheck, pre- and post-flight script phases. You cannot add more installation panels/pages without doing something really unpleasant such as overriding ObjectiveC code. This has nothing to do with PackageMaker itself. It's just that the Installer.app in 10.3 does not support as much stuff as it does in 10.4. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Installer plugins on 10.3
by Mike 24 Jul '07

24 Jul '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.5 (Macintosh/20070716) Mike On mardi, juillet 24, 2007, at 03:51 AM, Mike wrote: I've also set the Gestalt in the installer to allow 10.3 and 10.4. A miracle. Plugins are only supported on 10.4 and later. _______________________________________________ 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.… So how does one then go about creating any kind of a custom installer using Packagemaker on a 10.3 system? Stéphane Sudre wrote: I have metapackage intsaller I build under 10.4. and Packagmaker 2.1.1. My installer has 5 plugins and they all work great under > 10.4.x. When I run the same installer on 10.3.9, the installer runs fine, but the plugins never show up in the list on the left and never execute. I've verified that my InstallerSections.plist file and plugins are in the correct locations. What else do I need to do on 10.3 to get the plugins recognized or aren't they supported on 10.3 at all? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Installer plugins on 10.3
by Stéphane Sudre 24 Jul '07

24 Jul '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On mardi, juillet 24, 2007, at 03:51 AM, Mike wrote: I've also set the Gestalt in the installer to allow 10.3 and 10.4. A miracle. Plugins are only supported on 10.4 and later. _______________________________________________ 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 metapackage intsaller I build under 10.4. and Packagmaker 2.1.1. My installer has 5 plugins and they all work great under > 10.4.x. When I run the same installer on 10.3.9, the installer runs fine, but the plugins never show up in the list on the left and never execute. I've verified that my InstallerSections.plist file and plugins are in the correct locations. What else do I need to do on 10.3 to get the plugins recognized or aren't they supported on 10.3 at all? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Quitting applications on InstallationCheck
by Stéphane Sudre 24 Jul '07

24 Jul '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On lundi, juillet 23, 2007, at 09:10 PM, Fritz Anderson wrote: _______________________________________________ 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.… [...] What does my tool return, if the user presses Cancel? I tried 3, and found that the installation continued unimpeded. I tried 96 + 3 = 99, and Installer.app crashed, I assume because it couldn't find a matching message string, and didn't check to see if the message was NULL. Don't forget to file a bug report. There's no reason why it should crash in this case. This email sent to site_archiver(a)lists.apple.com

1 0

Installer plugins on 10.3
by Mike 24 Jul '07

24 Jul '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.5 (Macintosh/20070716) I've also set the Gestalt in the installer to allow 10.3 and 10.4. 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.… I have metapackage intsaller I build under 10.4. and Packagmaker 2.1.1. My installer has 5 plugins and they all work great under 10.4.x. When I run the same installer on 10.3.9, the installer runs fine, but the plugins never show up in the list on the left and never execute. I've verified that my InstallerSections.plist file and plugins are in the correct locations. What else do I need to do on 10.3 to get the plugins recognized or aren't they supported on 10.3 at all? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Quitting applications on InstallationCheck
by Bill Coderre 23 Jul '07

23 Jul '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thank you, Bill, for the background and help. Bit 8 is reserved and must always be 0. On Jul 23, 2007, at 12:10 PM, Fritz Anderson wrote: On 19 Jul 2007, at 5:51 PM, Bill Coderre wrote: Apple's policy (which is not followed 100%) is to put up an error immediately if the target app is running. To do this, check for the app running in your InstallationCheck script (or similar part of the distribution script), and just return an error. This means that the user has to switch to the other app, save and close, quit the installer, and then re-run the installer. That's a bit lame... As an experiment, I've tried including, as InstallationCheck, a Foundation/CF/Carbon tool that, if it finds the target application running, posts a CFUserNotification alert asking the user to quit the target and press Continue, or to press Cancel to abandon the installation. I get the "This package contains a program..." alert, but probably it can't be helped, and it's a policy issue as to whether we can live with it. What does my tool return, if the user presses Cancel? I tried 3, and found that the installation continued unimpeded. I tried 96 + 3 = 99, and Installer.app crashed, I assume because it couldn't find a matching message string, and didn't check to see if the message was NULL. Am I going astray here? Your unix executable should return an InstallationCheck error code byte. This is documented somewhere, but here's the quick explanation. The real documentation should be considered to be more accurate than mine. Start with 8 bits of 0, and set the number of the error message to be returned. If you set a number from 1 - 15, you get a predefined error message. They are currently set as follows: 1 - Displays message "This software cannot be installed on this computer." 2 - Displays message "The software <blah> cannot be installed on this computer." 3 - Displays message "<blah> cannot be installed on this computer." 4 - Displays message ""An error was encountered while running the InstallationCheck tool for package <blah>." 5 - Displays message about how your system has Tier3, so you can't install. (Tiger and later, only) 6-15 Additional predefine messages supplied by the Installer (currently undefined). If you specify a value from 16 - 31, the error is looked up in InstallationCheck.strings, in an appropriate lproj as necessary for localization. Here's an example of such a file: "16" = "Mac OS XI is required for installation."; "17" = "There is already a newer version of this software on this system."; "18" = "Please quit the program Foo and try your installation again."; Then set bits 6 and 5 as follows: Bit 6 Bit 5 Meaning 0 0 Success - Installation to proceed as normal 0 1 Warning - Present the user a warning panel and allow install to proceed. 1 0 Fail Silently - Current package is skipped without showing any feedback. 1 1 Fail installation with error message shown. Note that the "warning" and "fail silently" modes do not work consistently in all installation situations. For instance, "fail silently" probably only operates as expected when the package is part of a bigger mpkg. [I can't recall all the details, and the results may vary between 10.1 and 10.3.9. (10.4 and later should work the same as 10.3.9. If your software is to support 10.2 and later, I'd make your installer support ONLY 10.2.8, 10.3.9, and 10.4.10 and later, if possible. That will make life a lot simpler.)] Most likely, you will already know that you want to the installer to stop, throw up an alert, and show string #17 (say), so your InstallationCheck executable would return 32 + 16 + 17. Note also that if you have a standard unix executable, which returns 0 on noError and >0 on error, and you wish to wrap it up and use it in a typical perl InstallationCheck, you'll need to call perl's "system" call roughly as follows: system($ARGV[0] . "/Contents/Resources/unixCheck", ... ); # Add any command line args my $result = $? >> 8; if ($result) { $EXIT_VALUE = ( ( 1 << 6 ) | ( 1 << 5 ) | 18 ); # always stop with error 18 last; } The first argument of the system call is the path to the executable, and $ARGV[0] in perl is the path to the installer package in question. I put my executables in Contents/Resources. perl's "system" call is a bit strange, since the return code is offset by 8. Read up on this if you're not familiar with the details. _______________________________________________ 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: Quitting applications on InstallationCheck
by Fritz Anderson 23 Jul '07

23 Jul '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On 19 Jul 2007, at 5:51 PM, Bill Coderre wrote: Thank you, Bill, for the background and help. Am I going astray here? — F _______________________________________________ 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.… Apple's policy (which is not followed 100%) is to put up an error immediately if the target app is running. To do this, check for the app running in your InstallationCheck script (or similar part of the distribution script), and just return an error. This means that the user has to switch to the other app, save and close, quit the installer, and then re-run the installer. That's a bit lame... As an experiment, I've tried including, as InstallationCheck, a Foundation/CF/Carbon tool that, if it finds the target application running, posts a CFUserNotification alert asking the user to quit the target and press Continue, or to press Cancel to abandon the installation. I get the "This package contains a program..." alert, but probably it can't be helped, and it's a policy issue as to whether we can live with it. What does my tool return, if the user presses Cancel? I tried 3, and found that the installation continued unimpeded. I tried 96 + 3 = 99, and Installer.app crashed, I assume because it couldn't find a matching message string, and didn't check to see if the message was NULL. This email sent to site_archiver(a)lists.apple.com

1 0

NSImageView images not showing up in plugins
by Mike 21 Jul '07

21 Jul '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.5 (Macintosh/20070716) 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.… I have a Cocoa installer plugin which works fine except that I have 2 NSImageView items in the plugin's NSView which don't show up at runtime. I have two TIFF images added to my Xcode project and they show up fine in Interface Builder and are displayed in the NSImageView panes in IB but nothing shows up in the installer pane at runtime. Do I have to do anything special to get the images to show up in the pane at runtime? This email sent to site_archiver(a)lists.apple.com

1 0

Re: detect previous installation
by Stéphane Sudre 20 Jul '07

20 Jul '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On vendredi, juillet 20, 2007, at 10:38 PM, Michael Watson wrote: On 20 Jul, 2007, at 15:48, Stéphane Sudre wrote: - or you could save it into the Internet Config data base That's why it's a good idea (IMHO). Agreed. Yes, in a Tex Avery cartoon, why? _______________________________________________ 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.… Is this really a good idea? Doesn't sound like the proper sort of data to put here. - if your program runs as root, you have plenty of locations to hide it. This is /definitely/ going down the Road to Bad Ideas. Firstly, your program probably shouldn't be running as root. (DEFINITELY not if it's a GUI app.) Secondly, you may be opening yourself up to potentially nasty race conditions just to write some DRM registry file somewhere. I don't see how simply writing and reading a file can lead to a race condition when running as root as opposed to running as another user. Ever seen an exterminator attack a mouse with a nuclear warhead? This email sent to site_archiver(a)lists.apple.com

1 0

Re: detect previous installation
by Michael Watson 20 Jul '07

20 Jul '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On 20 Jul, 2007, at 15:48, Stéphane Sudre wrote: - or you could save it into the Internet Config data base -- m-s _______________________________________________ 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.… Is this really a good idea? Doesn't sound like the proper sort of data to put here. - if your program runs as root, you have plenty of locations to hide it. This is /definitely/ going down the Road to Bad Ideas. Firstly, your program probably shouldn't be running as root. (DEFINITELY not if it's a GUI app.) Secondly, you may be opening yourself up to potentially nasty race conditions just to write some DRM registry file somewhere. Ever seen an exterminator attack a mouse with a nuclear warhead? This email sent to site_archiver(a)lists.apple.com

1 0