i-Installer Design

Introduction

General behaviour, constraints and guidelines

• Installation. Installation consists of
  • An optional selection phase where the user may select which parts of a package need to be installed this time around. Often the selection phase is used without user interaction to choose which version of the data should be installed. E.g. when X11 is found, a different version of software is installed than when X11 is unavailable.
  • An optional preparation phase, normally used to remove any previous versions of the software (if necessary) to prevent the doubgle availability of moved files or the remaining availability of files that are not part of the package anymore.
  • An unarchiving phase where the data is unarchived.
  • An optional merging of installed data into resource forks.
  • A configuration phase.
• Configuration. This is equal to the configuration phase that takes place at the end of an install.
• Uninstallation.

i-Installer is designed to meet the following constraints:

• Functionality i-Installer should give feedback to the user to provide him or her with information from which can be deduced that the install process (which can be lengthy) is still running.
• Functionality Install and configuration actions are interactive and possibly authenticated.
• Functionality Dependencies may be of any of the foollwoing two types:
  • Required. Required dependencies are dependencies the package defines as those which need to be met for the installed software to function correctly. An example is a prerequisite dynamic library without which the software in the package will just not launch.
  • Recommended Recommanded dependencies are dependencies that improve the working of the software or the package, but without it the software will work. An example is the availability of ghostscript for ImageMagick. Without ghostscript ImageMagick cannot preform certain conversions but it will work for others. Another example is the availaibility of FontForge for the TeX i-Package. When FontForge is available, the TeX i-Package can convert the installed Latin Modern font for use in other applications beside TeX.
• Security Though mechamisms like GPG and MD5 are used to establish authenticity of package contents, the final source of security in i-Installer is the user. No install action shall therefore be taken without explicit acknowledgement by the user. Hence, if one package requires (or recommends) the availability of other software, the required software (if available as i-Package) shall not be installed automatically. However, in the future, multi-packages may be available, combining existing packages.
• Good citizenship i-Packages may be mixed and matched with other ways of installing and configuring software. Hence, i-Installer does not force you to do everything with i-Installer (and thus also does not have the obligation to provide everything). It is perfectly OK to install the latest version of certain software yourself by downloading and compiling. i-Packages requiring that software will not demand that i-Installer is used to install the dependencies. It is perfectly feasible to use an i-Package to run a configuration action on software that was not installed with i-Installer.
• Networked i-Installer works with i-Packages that have a counterpart on the internet in socalled repositories. i-Installer will automatically detect changes in the repository with respect to the local i-Package and it will update from that repository. i-Installer will minimize network traffic and will only download those contents that are needed for the function the user has chosen.

• Functionality i-Installer uses gnutar as the archiver.
• Security i-Installer uses the Apple Security Framework to run authenticated subprocesses. Hence, authentication times out after 5 minutes and long installs may require authentication by the user more than once.
• Functionality i-Installer uses the Foundation Framework for network traffic. Hence, it both benefits from the functionality, but suffers from bugs (e.g. ftp does not work properly and the use of the Framework might crash the OS entirely, though this is extremely rare) and limitations of that Framework. Currently, the class most heavily used is NSURLHandle. Mac OS X 10.3 has more functionality (and probably fewer bugs) in newer classes, but using these would imply dropping support for Mac OS X 10.2 entirely.

Some consequences

• Feedback if something is happening during the running of phases is not implemented yet with the exception of the unarchive phase (and that only for packages that have the information to support it).
• When program-based phases are executed, they can be anything and do anything. i-Installer is therefore limited in drawing conclusions from what is going on. In fact, it only recognizes two outcomes: success (unix level return value ≡ 0) and failure (unix level return value ≠ 0). A return value ≠ 0 stops the process and reports an error. However, in some cases there will be errors in the subprocess but still the program reports success. An example is (again) TeX, which considers failures generally to be inside its domain (a reasonable and correct attitude in itself: TeX itself does not fail, but the data provided to it is faulty). Hence, success is not by definition success. Absence of proof of failure does not constitute proof of absence of failure. Hence, i-Installer reports on succesful completion the lack of critical errors (errors producing nonzero results), but cannot guarantuee that nothing went wrong inside. The word critical is correct, but may confuse users.