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

My Disc 2/Multiple Disc Installs
by Sam Fischmann 16 May '07

16 May '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.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Installer Plugins - how to run as root?
by Mike Fischer 14 May '07

14 May '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Am 14.05.2007 um 21:05 schrieb Andy Kim <andyk(a)mxplay.com>: How do I access INSTALLER_TEMP from an Installer Plugin? It's not stored as an environment variable, I don't see it a getter for it in any of the Installer*.h files, and none of the standard folder methods return the same value: I'd be very interested in the answer as well. Mike -- Mike Fischer Softwareentwicklung, EDV-Beratung Schulung, Vertrieb Web: <http://homepage.mac.com/mike_fischer/index.html> Note: I read this list in digest mode! Send me a private copy for faster responses. _______________________________________________ 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 used /tmp and a UUID filename to avoid conflicts for one of my Installers because I didn't find any solution to this. This email sent to site_archiver(a)lists.apple.com

1 0

Re: UI (Installer Plugins) and headless installations
by Mike Fischer 14 May '07

14 May '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Hi Peter, Hello Mike, Sunday, May 13, 2007, 1:23:51 AM, you wrote: For example, in one project, for which I wrote an installer, the installed software is basically a UNIX daemon + additional supporting files. But it also needs an Installer Plugin for entering the license number (it is commercial software) and choosing some options which would be very awkward to do at any other point in time or through any other method. Why not simply make a small program that pops up a dialog for the user to enter the code, and then run this in your installers Postflight script ? Not really an issue for my specific case at the moment. Thanks! Mike -- Mike Fischer Softwareentwicklung, EDV-Beratung Schulung, Vertrieb Note: I read this list in digest mode! Send me a private copy for faster responses. _______________________________________________ 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.… Am 14.05.2007 um 21:05 schrieb Peter Mulholland <darkmatter(a)blueyonder.co.uk>: Well for one it would force the user to enter data during the actual install. Secondly it doesn't really help with the ARD or CLI cases AFAICT. Third, the Installer Plugin is already implemented ;-) That will work on 10.3 and earlier as well, then. Anyway, I'm more interested in a general answer to my question of how to reconcile the need for additional user input with ARD or CLI installs. I have a working solution for the case where Installer Plugins (or other interactive GUI) are possible. It's probably easier than writing an Installer Plugin too (trivial with NIB files for the GUI) Writing an Installer Plugin was very easy as well. With better documentation (or any at all) it would be just as trivial. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Installer Plugins - how to run as root?
by Andy Kim 14 May '07

14 May '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.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: UI (Installer Plugins) and headless installations
by Peter Mulholland 14 May '07

14 May '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Hello Mike, Sunday, May 13, 2007, 1:23:51 AM, you wrote: > For example, in one project, for which I wrote an installer, the > installed software is basically a UNIX daemon + additional supporting > files. But it also needs an Installer Plugin for entering the license > number (it is commercial software) and choosing some options which > would be very awkward to do at any other point in time or through any > other method. Why not simply make a small program that pops up a dialog for the user to enter the code, and then run this in your installers Postflight script ? That will work on 10.3 and earlier as well, then. It's probably easier than writing an Installer Plugin too (trivial with NIB files for the GUI) -- Best regards, Peter mailto:darkmatter@blueyonder.co.uk _______________________________________________ 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: UI (Installer Plugins) and headless installations
by Mike Fischer 13 May '07

13 May '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Hi Stéphane, Am 13.05.2007 um 17:14 schrieb Stéphane Sudre: On dimanche, mai 13, 2007, at 02:23 AM, Mike Fischer wrote: AFAIK, there are not only 2 cases but 3 with this scenario: (1) Manual Installation (2) Terminal/Shell Installation (3) ARD Installation (1) can use Installer Plugins (2) (and (3) AFAIK) can not Thanks for your comments! Mike -- Mike Fischer Softwareentwicklung, EDV-Beratung Schulung, Vertrieb Web: <http://homepage.mac.com/mike_fischer/index.html> Note: I read this list in digest mode! Send me a private copy for faster responses. _______________________________________________ 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.… [...] As long as a GUI is available Installer Plugins are a great solution to this problem. But how can this be solved for the above mentioned CLI installer or the other cases Peter referred to? Other than completely abandoning the Apple Installer technology and going back to the interactive CLI installation process the client originally used I see no solution. Offering both would be possible but would also require supporting two installers for Mac OS X and it would involve distributing about twice as much data since the packaging methods are completely different + appropriate documentation. Comments anyone? Yes you are correct. I had not taken ARD into account. Thanks for the reminder. Unfortunatly I have never had the opportunity to actually see ARD. (The same probably goes for most people unless they are supporting a large number of Macs.) I'm pretty sure it's cool technology but since only paying customers have access many developers will only look at it when they have the very specific need to do so. Documentation seems mostly non-existant, apart from the rather short mention in the Software Delivery Guide chapter "Performing Remote Installs". This chapter does not mention any limitations w.r.t. Installer Plugins though reading between the lines it's obvious that an Installer Plugin can't be used in this scenario. Actually doing a search on developer.apple.com for "Installer Plugin" yields exactly 2 results, both pointing to the InstallerPluginSample sample code. It seems Installer Plugins are completely undocumented apart from this sample code and the header files? The issue is that assuming a solution can be found for (2) when using Apple packages, it would not be ideal for (3) since showing a CLI in ARD can be very confusing to the user. Yes, unless ARD had a supported way of passing individual configuration parameters to a list of client machines I don't see how this could work at all. Re-Packaging everything in Apple packages would be possible in theory, though the cost of doing so may make this impractical. (This would not be a one-time effort but would need to repeated whenever the software is updated.) If (and I would be surprized at this capability) ARD allowed for interactive command line execution of scripts on more than one client, it would definatly be a UI nightmare. The only way I could see something like this work would be to provide a) a generic, possibly extendable, GUI for specifying individual parameters for the clients and b) an extension to the current Installer Plugin mechanism that separates the GUI (view) part from the data (model and controller) part. For plugins factored in this way it might be possible to build an alternative "mass-entry" GUI mechanism for the data and have the back-end run on the individual clients to process the data. Or in some cases it might even be possible to use a generic GUI for the front-end. I posted my question for two reasons: - To find out if I had missed something important; - To start a discussion that might lead to ideas for improving the Apple Installer or to at least raise awareness for the limitations. Of course once suitable ideas pop up they would need to be submitted as bug reports, enhancement or feature request. I did not want to start on this while I have the strong feeling of not seeing the whole picture. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Installer Plugins - how to run as root?
by Andy Kim 13 May '07

13 May '07

site_archiver(a)lists.apple.com Delivered-To: Installer-dev(a)lists.apple.com What Stéphane said. Also, I filed the following bug feature request: bool YesNoDialog(string question, bool defaultIfSilent) On May 11, 2007, at 5:30 PM, Peter Bierman 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.… #5199577 - add simple dialog api for user input callable during installer scripts Summary: In certain cases, it would be useful to receive user input or display an alert dialog during the Apple Installer script phases (preflight, postflight, etc.). Since there is currently no built-in method to do so, this can lead to a poorer user experience and poor practices during installer authoring. A supported API for dialogs during scripting phases would lead to a better user experience and could enforce best practices. Notes: One such example where a dialog API would be useful is when launching a third-party installer from a script. A requirement from the third- party is that their application binaries cannot be repackaged so the installer must be launched. If the user cancels the third-party installer, then it might be useful to display an, "Are you sure? The third-party install is required to continue." dialog. A general use- case is a runtime error that cannot be detected before preflight (where an installer plugin may be used), which you want to give the end-user a chance to recover from that error. Current workarounds might include displaying an AppleScript dialog or creating a custom application just for that dialog. Neither workaround is ideal. Unless the installer developer has the foresight to special-case command-line installs, these dialogs would appear. In addition, it creates added complexity to create a dialog one might expect from a simple function call. Pseudocode for such a function signature might look like this: where defaultIfSilent is the value returned if the installer is run from the command-line. Moreoever, since defaultIfSilent is required, it enforces the best-practice of designing for a command-line install. What's "Klingon UI input"? This email sent to site_archiver(a)lists.apple.com

1 0

UI (Installer Plugins) and headless installations
by Mike Fischer 13 May '07

13 May '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Hi, Make sure your software doesn't _require_ the plugins to install. There are several situations under which the installer is unable to load plugins. They're intended for optional use, with the presumption that any required actions can also be done in the app itself, if the app is installed via a mechanism that doesn't support the plugins. Comments anyone? Thanks! Mike -- Mike Fischer Softwareentwicklung, EDV-Beratung Schulung, Vertrieb Web: <http://homepage.mac.com/mike_fischer/index.html> Note: I read this list in digest mode! Send me a private copy for faster responses. _______________________________________________ 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.… Peter Bierman recently wrote an answer to a different question which rang a bell for me: The command line installer is the simplest example, but there are many others. This seems to assume that an application in the most normal GUI sense is being installed. Possibly I'm taking this out of its original context and interpreting too much into this answer but as it stands I see a big deficiency in the current Apple Installer technology. For example, in one project, for which I wrote an installer, the installed software is basically a UNIX daemon + additional supporting files. But it also needs an Installer Plugin for entering the license number (it is commercial software) and choosing some options which would be very awkward to do at any other point in time or through any other method. There is no GUI application where any of this could happen. The closest this software comes to having a GUI is that it provides its own dedicated HTTP-Server (on a non-standard TCP-port) for configuration and status information. As this is a cross platform software (Win and UNIX including Mac OS X) and the client (the maker of this software) wants to avoid Mac OS X specific changes my only option was to take the command line setup script the client used to provide, remove everything that was not needed on Mac OS X and turn the rest into an Installer Package. The license number is parsed and used to make a number of decisions inside the installer (be it CLI script or .pkg) which define exactly which components get installed. So without the license number the installation is not possible. The same goes for some other parameters that my Installer Plugin currently allows the user to enter. Now you may say that the problem is with the design of the cross platform part of the installer and I'd agree. But OTOH the client does not wish to invest serious time and money into retooling and testing an installation process that already works on many different platforms, just so that a few Mac users can get an optimal installation experience. They do want to conform to what the Mac OS X users expect as much as possible though which is why they hired me to create the Mac OS X installer. To put this into more general terms: there may be real world reasons requiring a user to enter data before an install. As long as a GUI is available Installer Plugins are a great solution to this problem. But how can this be solved for the above mentioned CLI installer or the other cases Peter referred to? Other than completely abandoning the Apple Installer technology and going back to the interactive CLI installation process the client originally used I see no solution. Offering both would be possible but would also require supporting two installers for Mac OS X and it would involve distributing about twice as much data since the packaging methods are completely different + appropriate documentation. This email sent to site_archiver(a)lists.apple.com

1 0

Distribution Scripts - Documentation?
by Mike Fischer 12 May '07

12 May '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Hi, But that seems to be it in terms of documentation? Thanks! Mike -- Mike Fischer Softwareentwicklung, EDV-Beratung Schulung, Vertrieb Web: <http://homepage.mac.com/mike_fischer/index.html> Note: I read this list in digest mode! Send me a private copy for faster responses. _______________________________________________ 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'm currently trying to evaluate if distribution scripts will make certain things easier in building an installer (meta-)package. Have I been missing something or is the documentation in this area really sparse? I have looked at: - Software Delivery Guide (<http://developer.apple.com/documentation/ DeveloperTools/Conceptual/SoftwareDistribution/index.html>) - Installer Release Notes for 10.4 (<http://developer.apple.com/ releasenotes/DeveloperTools/Installer.html>) So far I have accumulated some concrete questions that I had hoped could be answered by reading the appropriate documentation. But I didn't see the answers to these questions anywhere: - Is it possible to use distribution scripts in conjunction with a user-selectable install destination? I have a distribution package containing several plain packages (.pkg) which all have IFPkgFlagRelocatable set to Yes. This works fine in a metapackage (it shows a button to allow the user to select the destination folder in the "Select Destination" pane after choosing a destination volume) but it seems to be ignored in the distribution package. - Why does the Installer use a resizable window when using distribution scripts? The same package built as a plain (Info.plist) metapackage gets a fixed size window. This is relevant because the Installer uses a background image which looks bad when stretched. (And it would also look bad when used in a larger window and fixed to any corner.) - Would distribution scripts help to require admin authentication only when it is really needed? By default the install goes into /Applications so it needs admin authentication. But non-admin users should be allowed to install into their home directory (see first question) without being asked for admin credentials. I am looking at distribution scripts to see if they can help solve this problem. - What is the preferred/supported way to test for the processor architecture (PPC vs. Intel) in a distribution script? Currently I compare the output of system.sysctl('hw.machine') to "Power Macintosh" and "i386". But strangely this sysctl selector is not included in the presets that PackageMaker provides. This make me wonder if that is the best way to test this. Would testing system.gestalt('sysa') for result '2' or '10' (gestaltSysArchitecture is gestaltPowerPC or gestaltIntel) be a better way to do this? - Should a dispribution package (.mpkg containing a distribution.dist file) generate an appropriate error message when opened on a pre 10.4 system? If not, how can I achieve this? My tests so far seem to indicate, that no error message is presented to the user on a 10.3.9 system, but that the Installer will launch without any open window when a distribution package is opened in the Finder. That is a very bad user experience IMHO and seems to be a design flaw in the Apple Installer? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Installer Plugins - how to run as root?
by Stéphane Sudre 12 May '07

12 May '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On samedi, mai 12, 2007, at 02:30 AM, Peter Bierman wrote: Maybe something like this: +-------------------------------------------------+ | Alert! | +-------------------------------------------------+ | | | Something bad happened during the installation. | | Do you want to make things worse and erase | | all the disk partitions? | | | | [x] Include network volumes and iPod | | | | ( Yes ) | +-------------------------------------------------+ _______________________________________________ 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's "Klingon UI input"? but more probably it could mean better error message(*) when installation fails or being able to provide custom messages for installation error (such as contact our support at this e-mail address). * In some cases, the reason of the error is detailed in the log but the error message displayed to the user is something like: "It failed.". This email sent to site_archiver(a)lists.apple.com

1 0