You won't believe it, but this program actually has attracted fan mail (and some hate mail). An edited selection of fan mail can be found here
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 an installed 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. As of Jan 1, 2007, the current set is (this may change without notice):
The following packages are available from me (unsupported):
Some others provide i-Packages as well. There is a package for the JOVE emacs-like command line editor, provided by Tom Hageman.
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 for more info.
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 an APple Installer.app .pkg. To install i-Installer, install the .pkg. Once installed, i-Installer can be used to update itself.
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.
E-mail about i-Installer can be sent to ii2 at rna dot nl. Note that this address may be protected by an anti SPAM system, in which case you'll get a robot-reply to tell you how to reach me.
Please read the top of this page carefully. Bugs may be reported but I do not support this software anymore except for my personal use, hence, fixes may or may not come and may take a long time to come. If you report a bug, make sure to include.
- What you did.
- Your OS version and what you can tell me about what is installed.
- For i-Installer and i-Packages
- In case of an i-Installer crash: the crash log.
- In all cases: the log output in Console.app. If the problem is reproducible, set i-Installer to a higher log level (e.g. 6) and recreate the problem. Send me that Console.app output.
- The contents of a report (see below) *after* the error has occurred. In case of a crash, from before the crash occurs.
i-Installer has a menu option Create & Display Report in the i-Package menu, which you should use preferably and if possible. This creates a report on settings, properties, output, etc. of you i-Package. If you select the menu item, a special tab view opens in the i-Package window. There you find a mail button to send it to me.
Correct. Mac OS X 10.2 and older versions are not supported. Mac OS X 10.1 and older are not supported at all and no i-Installer version will run on them. For Mac OS X 10.2 you can download a volume of 357MB which contains a snapshot of i-Installer.app and all my i-Packages from Jan 24, 2006. All of these should install and work on Mac OS X 10.2. However, there have been so few users actually running 10.2 lately that this is not guaranteed.
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.
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.
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.
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:
- Update the package (in the properties tab, click the update button). Note: this will remove any parts of the local package that have changed. So if your package is complete (fattened), back it up first en restore it if you decide you want to go back to the old situation. The message view will tell you which files have changed and have therefore been removed locally.
- Now, in the inspect tab, you can see which files are available. Suppose the archive (normally the biggest part) has been removed because it has changed. Inspect the README (which should have been changed as well). The README should tell you (if the package maintainer is doing his work properly) what has changed and you can decide if you want the update or not. If you do not, you may restore the backup to get your old situation back.
Note: This procedure is very wasteful. You will be downloading everything in an i-Package, far more than you need. Also, this only works for my repository which is available via ftp.
Go to a machine that has a fast internet connection. Any machine will do, but the following instructions are based on a unix machine using the ncftp command. If you go to a Windows machine, do the equivalent, but then in Windows (and I do not know how).
- Change directory to where you want the i-Packages. E.g. cd ~/Desktop
- Get the i-Packages (approximately 300MB!):
ncftpget -R ftp://ftp.nluug.nl/pub/comp/macosx/i-packages
- Get i-Installer:
ncftpget ftp://ftp.nluug.nl/pub/comp/macosx/volumes/ii2/II2.dmg
Ignore all i-Installer warnings you get about not being able to find stuff on the internet. Best is to start i-Installer, and set network preferences to no network traffic at all.
- Copy the i-packages directory and II2.dmg to an USB stick or a CD and bring it to your Mac.
- On your Mac, open II2.dmg and install the Installer.app .pkg on that volume.
- Log out and log in (to get .ii2 and .iid recognized by the system, this might not be needed on recent versions of the OS)
- Double click <wherever your stuff is>/i-packages/iid/gwrelative.iid
- Open and install the i-Packages you require
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.
Thirdly, i-Packages may be retired and these only support uninstalling.
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.