Miscellaneous details

How does i-Installer.app detect installed packages?

After a succesful completion of an unarchive or configure operation of package foo.ii2, i-Installer.app will write a small file in /Library/i-Installer/Receipts. This file contains information on the package and the status of the install.
After succesfully running the remove script from package foo.ii2 i-Installer will remove that file.

i-Packages themselves may override the removal behaviour in the scripts. For instance, the ghostscript 7 package might remove the stamp file for ghostscript 6 (and vice versa) as both packages write partly the same files. This is a suboptimal solution as some files of the overwritten package may remain. It is always better to remove the old before installing the new if they overwrite each other. A dependency is a better solution for this problem.

How does i-Installer.app support dependencies?

A package can depend on other software. For instance, package might contain programs that link dynamically against a library (from another package possibly). Or a package might need the absence of other software to function well. Or a package might work without other software, but it might work better when the other package is installed. Package designers can take these situations into account. i-Installer detects on the basis of file information, but it may offer to open packages when it knows that for that specific file a package is available.

If a package depends on other software, the information is available in the table of contents. When you try to install the package (and only then, not when you uninstall or configure) these dependencies will be checked and the check results will be displayed in the message view. When i-Installer detects a dependency problem, it will present a warning sheet, asking you for a decision. The following situations may occur:

Required or recommended software is missing. Without that other software installed, the software in the current package will not work (in case of required software) or work less well (in case of recommended software).
Non-compatible software is available. The software in the current package will not work unless the non-compatible software is removed.
From a set of softwares, the installation of one and only one is required (or recommended), as in the case of ghostscript when installing ImageMagick: you either install ghostscript 6 or you install ghostscript 8. You are presented with a popup list of package descriptions with the question which you want to open. You might choose to open all (for instance if you want to remove one and install another). Some intelligence from your side is required, i-Installer will never install anything without user intervention and if you are told you need one and only one, you can ignore that, but at your own peril.

Required dependencies are important. Often software will not function at all (and even crash) if these requirements are not met. Recommended dependencies may improve the working of software or even improve the functionality of a package. But recommended dependencies may be circular. E.g. TeX can work fine without ghostscript, but you need ghostscript to produce PDF via TeX's dvips. TeX, therefore, works better with ghostscript. Ghostscript works independently from TeX, but a ghostscript package may be able to take the Postscript fonts installed by TeX and add them to the ghostscript setup. Ghostscript is richer as a result. As a result, TeX and ghostscript are interdependent, but only at the recommended dependencies level.

In preferences it is possible to switch the package dependency checking between

Required dependencies only. This is the default mode.
All dependencies
No checks.

How does i-Installer locate packages when handling dependencies? The following search order is maintained:

It tries to find the package in the same directory on disk as where the package requesting the opening of the new package resides.
It tries to find the package in the default save location for packages created from remote locations.
It replaces the package name in the URL of the current package with the name of the new package and tries to open it remotely. This means that package designers should distribute depending packages side by side.

In other words, suppose the default save directory is ∼/Documents. And suppose you have package ImageMagick.ii2 open from the directory ∼/Desktop. And suppose its URL is http://tug.org/i-packages/ImageMagick.ii2. If package ∼/Desktop/ImageMagick.ii2 tries top open dependency freetype2, it will try

∼/Desktop/freetype2.ii2
∼/Documents/freetype2.ii2
http://tug.org/i-packages/freetype2.ii2

It might be clear from all this that it is generally a good idea to keep your i-Packages in a single directory and make that directory the default save directory.

How does i-Installer.app handle remotely updated packages?

i-Installer will on opening of a package look at the rmeote location and see what version lives there. It will update this often (e.g. when you hit Install). If the remote version is different, you will normally get a panel asking you what you want. The choices are:

Cancel. Do nothing.
Update and proceed.
Ignore. This option you will only see if for the current action all relevant parts are available in your local package (in other words: if you do not need a download to proceed). Note that in the case of packages that contain multiple sets it is not known in advance what is needed. In that case, choosing Ignore will go ahead with the selection phase. When the selection phase has finished and it turns out that everything for your selection is available, installation will proceed with the data in your (local) package. If however some files are missing, installation will be aborted.