Development Structure

There are four parts to the intimate development structure. Website, Base Image, Repositary and Installer. Each of these different sections is set up so that many people may work on each section independantly. There's a round-up of each area below. Hopefully this will give everyone an idea of how it all fits together, what needs doing, and how it can be done :)

Website

The website is hosted on handhelds.org. The intimate project has a /home/intimate directory in which all the files relating to the project live. The website itself is in /home/intimate/website/data. The site now uses server-side includes to include common page elements. This means that you don't have to worry about the page format if you're writing HTML docs. Just a plain blank page will do. The logo and sidebar can be added with a simple #include. In order to work on the site, you will need an account on handhelds.org, and membership of the intimate group. FTP is used to transfer files to/from the server, so a shell account is not required. Only FTP access is needed.

Base Image

The Base image is the section which is transferred onto the iPAQ during the rsync portition of the install. The base image fulfills the same role in intimate that it does in debian. Namely, a basic text-only setup which will allow you to install and configure additional packages. The current base image was made by starting with a debian2_2.tgz stable ARM base, configuring it for booting on the iPAQ, and then upgrading it to use debian_unstable packages. The base image is currently around 56MB in size. Most of the packages on the base are not likely to change, but configuration files on the base are still in need of significant modification. The base also needs periodically updating with an apt-get upgrade to keep it up to date with debian's unstable feed.

The base image is manipulated entirely using rsync. rsync is an open source utility that provides fast incremental file transfer, complete with error checking, and CRCs etc. It's effectively equivalent to 'cp' but for use between remote machines. You can sync in either direction, pulling files from the server to yourself, or vice vera. You can sync individual files, directories or whole disks. It's in every way just as useful, powerful and potentially harmful as the 'cp' command.

Because of this, there are two different versions of the rsync image. The release version, and the development version. The release version of the image is read-only, and no further changes are allowed to the release image once it has been released. The development image can be written to by authorised rsync users. (You do not need an account on handhelds.org for this. You just need to convince us to give you write-access to the rsync development stuff). Due to the lack of any kind of rollback, journaling, tracking, or any of the other useful things that makes CVS so good, the development image will need a good thorough testing before release. (Really, we want some kind of CVS for binary files, which maintains file permission and ownership information... If anyone has a suggestion.. please.. please)

Repositary

Intimate now pulls packages from a mixture of the debian repositaries, and a repositary held on handhelds.org. By placing packages on handhelds.org, we can offer them uniquely to intimate users, without breaking any regular debian users. For example, we can out-version debian on their own packages, to work around bugs (perl currently only works because we out-versioned debian). We can release packages which replace and obsolete existing debian packages, so they will be installed in preference on the iPAQ.

The intiamte .deb repositary is held in /home/intimate/website/data/debian . It fully matches the debian directory structure, as this is what apt-get and dpkg expect to work with. All the packages currently live under dists/unstable/main/binary-arm.

The 'Packages', 'Packages.gz' and 'Release' files are automatically generated by a script (./mkrelease) , which will parse the repositary for .debs, and extract the relevant information needed. The script also generates the Packages web page at the same time. The idea is to run this script whenever a new package is added to the repositary. The script is currently very very dumb. It performs no error checking whatsoever, and will dumbly just grep and echo information into the relevant files. If a single error exists within the resulting Packages file, then apt-get will fail, and no-one anywhere will be able to use the repositary (neat huh?... no.. not really).

Currently, to get a package added to the repositary, you need to be in group intimate on handhelds.org (so you can run the script etc). This means that we can all add packages to the repositary... If someone mails a package to an intimate developer, then they can add it by executing a single command.

The ./mkrelease script needs a lot of work. Ideally, we'd have a fully automated package check-in. (Maybe something html based?). Please someone.... please :) Also, we need every util ever made or customised for the iPAQ to be packaged up and added to the repositary... Plenty of work for everyone here :)

Installer

The installer is a bit of shell script, and any associated binaries that are needed. It is assumed right from square one that an Internet connection direct to the iPAQ is available, so the standard install procedure is to wget the installer script, and execute it. The script will then fetch any additional files needed during the install procedure. (for example, the util to display a bitmap on the screen, and the bitmap to be displayed... the music player, and some music to play etc etc). This enables us to have an installer script that can cope with many different configurations, without having an un-necessarily large archive to store it all in.

There's still lots of stuff that needs adding to the installer script.. for example, we don't check to see if a disk is mounted before we fdisk, mkreiserfs or mkswap it. Now that blkmtd is around, we could offer the user a choice of filesystem to use... Smarter network autoconfig would also be good.. We want to try to make the isntaller script as smart as possible, so that the user need not be so smart.

To work directly on the installer script, you need to have shell access on handhelds.org... It stikes me that this would be a good one to put into CVS actually... Either way, there's plenty to be done here too.