i-Installer Home Page

You can support my work on i-Installer and my distributions. Click to make a donation via PayPal (major credit cards accepted). The software is free and open source, this is not shareware, you are allowed to use it without paying anything and my work on i-Installer is a philantropic activity. But donations are welcome to limit the financial damage ;-).

i-Installer is open source under a BSD License. i-Installer is hosted on
SourceForge.net Logo
You can get to the i-Installer project home page by following this link.

i-Installer code is not particularly good. This is the result of the fact that it has been written as a pilot-project-gone-awry in combination with the fact that certain aspects of the environment (Mac OS X) played foul with my original architecture ideas (it just did not work at that time). Mac OS X has improved since, but i-Installer would have to be rewritten to benefit. That is only going to happen if I win the lottery and do not have to work for al living anymore...

You won't believe it, but this program actually attracts fan mail. An edited selection of that fan mail can be found here

Introduction

Welcome to the i-Installer Home page. i-Installer is a network-aware installer application for Mac OS X 10.2 or higher. It installs i-Packages which are directories with a name ending on .ii2 and which contain a set of files. An in-depth introduction (in fact: the i-Installer Help Book) can be found here.

i-Installer is a generic software install and configuration application. It can install socalled i-Packages, which are wrappers (directories containing files) with names ending on .ii2 and which will look like files in most applications (like the Finder). i-Packages can be updated and downloaded from remote locations. Most of this will happen automcatically.

i-Packages may have the following functionality:

i-Packages may be interactive in a limited way. i-installer provides the package with access to several predefined sheets that can be displayed on the package window. That way, especially configuration can involve the user. (In other words: install TeX and select formats, languages in a GUI, install ghostscript and be offered a choice to add TeX's type1 fonts to ghostscript).

i-Packages exist just like other wrappers: on your hard disk. You can create packages from remote URL locations by entering an URL (like http://www.ntg.nl/macosx-tex/i-packages/texmf.ii2 in a panel.

However, the easiest way to create packages on disk from remote locations is using a "Known Packages" menu. This will list a series of packages and their location for you to choose from, called an i-Directory. The i-Directories may be local files or web based. My current set on the web is

These refer to each other in a circular manner . You can influence both the default i-Directory to use and the amount of descend into te web of i-Directories in i-Installers preferences. You can travel the i-Directory web in the Known Packages window.

The following packages are available from me:

Some others provide i-Packages as well. There is a package for the JOVE command line editor, provided by Tom Hageman, and one for XeTeX, a unicode version of TeX that can use the Mac System fonts directly, provided by Jonathan Kew.

Warning: as i-Installer depends on the web, you may encounter long time outs when servers are busy. See the performance section in i-Installer Help.

i-Installer offers the possibility for regular backgound (no need to start i-Installer, no need to be logged in) checking for new releases of packages you have available.

The i-Installer application download can be found here: II2.dmg. This will download a disk image. A disk image is a file that contains an image of a disk. Such a file can be used just like a disk can. You need to mount that disk image. Mounting a disk image can be done by double clicking it in the Finder.

When the disk image has been mounted, you will have an extra `disk' listed in your Finder window. On it you will find two files, a README file and the application itself. If you want i-Installer to be available permanently, copy the application on the mounted disk image to /Applications/Utilities by dragging it in the Finder.

Run i-Installer and (if you are connected to the internet) select the Known Packages submenu. You will be presented with a list of known packages. See my TeX page for more information on the TeX i-Packages and volumes and possible mirror locations.

The i-Installer volume is also mirrored. The following mirrors are available:

You are hereby granted permission to mirror the i-Installer volume, under the following conditions:

There is a mailing list for announcements about i-Installer.

i-Installer was designed and written by Gerben Wierda. The beautiful icons were designed by Jérôme Laurens.

i-Installer Know How

How and where do I report problems?

E-mail about i-Installer can be sent to: iinstaller@rna.nl Note that this address may be protected by a home-brew anti SPAM system, in which case you'll normally get a robot-reply to tell you how to reach me.

To be able to help I will need:

i-Installer has a menu option Mail Report in the i-Package menu, which you should use preferably and if possible.

Does i-Installer support authenticating proxies?

Sadly, No. The problem is mainly that the stuff in Cocoa I have used did not support this in the past. Only later versions of Cocoa have support for this and enabling this would require a complete rewrite of the download object (and dropping support for Mac OS X 10.2). This might happen, but not soon, and the main problem for me would be that I would be unable to test it (as I am not behind such a proxy myself).

What you can do instead is to download the package entirely through other means (like wget) and then use it from disk with network access for i-installer turned off.

The check of the remote package md5 checksum failed

A possible reason is that there is a cache between you and where your are downloading from and this cache is misbehaving. It is offering you an old version of the checksum or the table of contents even if there is a new version available *and* it is instructed by i-Installer to ignore caching (check your preferene setting on this).

An other possible reason is that you have been trying to update while the package was being updated. There is a protection against this in i-Installer, but this is not 100% proof as it would lead to unacceptable response times. If this is reproducable (i.e. it happens when you hit update again say one hour later) this update problem is not the cause.

It is as far as I know impossible for there to be another cause. i-Installer downloads the new table of contents and saves this (reporting download or write errors along the way). Then it checks the new table of contents (which has been downloaded) against the remote md5 checksum.

How do I check the up-to-dateness of i-Packages without running i-Installer?

i-Installer has a preference for this. You can tell it to check all i-Packages in the default save directory on a regular basis. You will get mail when one of them have been updated. See i-Installer help for details.

If you want to create a background check for packages in other locations, or just a few of the packages in your default save location, you need some unix knowledge. i-Installer writes its setting for this feature in the cron system. If you know how to edit this, you can easily copy and adapt the example that i-Installer writes there itself.

How do I minimize web traffic?

i-Installer itself minimizes web traffic by only downloading what is necessary for the action you want to perform (i.e. for removal, only the removal script is downloaded, not the archive itself). Read the help on inspection of archives to find out how inspection web traffic is minimized.

However, there is one thing you can do yourself. Suppose you have a package installed and an update has become available. You want to know if it is necessary to update and what will be downloaded, before actually doing the download, which you may want to do at another time. Here is how you go about it:

Why is button Foo disabled?

When i-Installer is performing a set of activities, most buttons are disabled. This is because the implementation of a combination of parallel activities is incomplete. When you download the archive because you want to install, hitting Inspect for that archive would start the same download and check set. These two sets would currently interfere.

Secondly, a package may be 'locked' (you see the small lock button on the package window). This is a protection against accidentally modifying a package hat is in 'useful' state. i-Installer will not modify the locked package (e.g. updating, fattening, etc). For instance, I ship a TeX volume with on it the latest i-Installer program and two i-Packages (TeX and ghostscript). Ghostscript is complete (fat). TeX is complete for a standard installation. Both are locked. They cannot be changed because they are on a read-only volume. But locking them also prevents i-Installer from actually trying. If you want to change such a package (e.g. update it), the best thing to do is first copy it to the default save directory of i-Installer, open it and unlock it.

After installing package Foo, the ownerhip of files and directories has changed!

This means that the package provider has included existing directories in the gnutar archive and gnutar creates these with the ownership in the archive, even if they already exist with another owner. The package provider can solve this problem by not providing directories, only the files in the directories. In that case directories are created when unavailable but not recreated or changed ownership when already available.