UI (Installer Plugins) and headless installations
UI (Installer Plugins) and headless installations
- Subject: UI (Installer Plugins) and headless installations
- From: Mike Fischer <email@hidden>
- Date: Sun, 13 May 2007 02:23:51 +0200
Hi,
Peter Bierman recently wrote an answer to a different question which
rang a bell for me:
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.
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.
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden