Miscellaneous details

How does i-Installer.app detect installed packages?

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 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

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

  1. It tries to find the package in the same directory on disk as where the package requesting the opening of the new package resides.
  2. It tries to find the package in the default save location for packages created from remote locations.
  3. 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
  1. ∼/Desktop/freetype2.ii2
  2. ∼/Documents/freetype2.ii2
  3. 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: